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1 Einleitung 


1.1 Die Debatte über IT-Offshoring: 
Internationalisierung und Industrialisierung von 
IT-Arbeit 


Betrachtet man die gegenwärtig geführte Debatte über die Verlagerung von 
hochqualifizierter Dienstleistungsarbeit in der Software-Entwicklung und den 
IT-Dienstleistungen aus den kapitalistischen Zentren in die aufstrebenden Nied- 
riglohnregionen der kapitalistischen Semi-Peripherie, so scheinen sich seit Ende 
der 90er Jahre große Veränderungen zuzutragen. Viele Autoren sind sich einig, 
dass sich die IT-Industrie in einer „neuen Entwicklungsphase“ befinde (u.a. Boes 
und Schwemmle 2004; Kampf 2008; Aspray, Mayadas und Vardi 2006; Sahay, 
Nicholson und Krishna 2003; Herbsleb und Moitra 2001; Oecking, Jahnke und 
Kiehle 2009), einige Autoren sprechen gar von einer „Revolution“ (Meyer 2006). 

Worin diese grossen Veranderungen gesehen werden, fasst eine Karikatur 
pointiert zusammen, die eine Bildersuche bei Google nach dem Terminus „IT- 
Offshoring“ als einen der ersten Treffer präsentiert: 


Ein Mann liegt weit zurückgelehnt auf seinem Schreibtischstuhl, die Füße 
auf dem Tisch, die Arme hinter dem Kopf verschränkt und mit einem 
entspannten Gesichtsausdruck. Das Schildchen auf seinem Schreibtisch 
weist ihn als „Star-Entwickler“ aus. Vor seiner Bürotür stehen zwei weitere 
Männer, im Gegensatz zu dem Mann am Schreibtisch tragen sie Anzüge 
und sind so als Vertreter des Managements erkennbar. Die beiden sind in 
ein kleines Gerangel verwickelt, in dem sie beide versuchen, als erster das 
Büro des „Star-Entwicklers“ zu betreten. Der eine Mann fleht dabei den 
anderen an: „Bitte, bitte - lass mich derjenige sein, der ihm sagt, dass wir 
seinen Job ausgelagert haben!“ 


Diese kleine Szene zeigt sehr anschaulich die beiden wesentlichen Aspekte, die 
im Zusammenhang mit der Verlagerung von IT-Arbeit gegenwärtig nicht nur in 
der Öffentlichkeit, sondern auch von wissenschaftlicher Seite diskutiert werden. 
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Zunächst spielt die Karikatur auf die konkrete Gefährdung von Arbeitsplätzen 
in den kapitalistischen Zentren an, die in der Karikatur in Form der unmittelbar 
bevorstehenden Kündigung auftaucht. Dies stellt für den IT-Bereich eine Neue- 
rung dar, da die Arbeitsplätze in dieser Branche lange als schwer verlagerbar und 
damit im Vergleich zu Arbeitsplätzen in anderen Industriesektoren als gesichert 
galten. Dementsprechend aufgeregt waren die Reaktionen, als kurz nach der 
Jahrtausendwende die ersten Hochrechnungen von Unternehmensberatungen 
über die Zahl potentieller Jobverlagerungen veröffentlicht wurden. 

Für diese Studie steht jedoch ein anderer Aspekt im Zentrum der Aufmerksam- 
keit, der in der Karikatur mindestens ebenso deutlich zu Tage tritt. Die Freude 
der beiden Managementvertreter, die sich darum reissen, dem „Star-Entwickler“ 
die Kündigung zu überbringen, verweist nur zu deutlich auf eine veränderte 
Machtverteilung zwischen Beschäftigten und Management. 

Die Körperhaltung des Entwicklers verweist (sicherlich übertrieben darge- 
stellt) auf zentrale Annahmen über Arbeit im IT-Bereich!. Die Branche befindet 
sich gewöhnlich im Fokus von Studien, die sich in unterschiedlicher Weise mit 
post-fordistischen Arbeitsformen beschäftigen. Unabhängig davon, ob eine ge- 
sellschaftliche Entwicklung hin zu einer Wissens- oder Informationsgesellschaft 
behauptet wird (Willke 1998, Heidenreich 2003, Castells 1996), ob die „New 
Economy“ mit ihrem „New Workplace“ der „Old Economy“ und deren taylo- 
ristischen Arbeitsformen gegenübergestellt wird (einen guten Überblick bieten 
dazu Thompson und McHugh 2002), Untersuchungsfeld ist immer auch die 
IT-Industrie, in der die angeblich „neuen Formen“ von Arbeit untersucht werden. 
Arbeit in der IT-Industrie komme demnach dem Idealtypus wissensintensiver, 
kreativer Tätigkeiten besonders nahe, weshalb ihrer konkreten organisatorischen 
Gestaltung weitreichende Konsequenzen für die Zukunft der Arbeit beigemessen 
werden. Durch die spezielle Qualität von IT-Arbeit, ihren wissensintensiven 
und kreativen Charakter, entzöge diese sich „traditionellen“ Formen der ma- 
nageriellen Kontrolle, worunter meist Formen bürokratischer oder direkter 


1 Das, was in dieser Arbeit im folgenden unter IT-Industrie (gleiches gilt für Begriffe wie IT- 
Arbeit, etc.) verstanden wird, bildet gemäß der Definition des Branchenverbandes BITKOM nur 
einen Unterbereich der Informations- und Telekommunikationsbranche (ITK) ab. Innerhalb 
dieser wird vom BITKOM zwischen den beiden Unterbereichen Informationstechnik und 
Telekommunikation unterschieden. Der Fokus dieser Studie ist auf den Bereich der Informa- 
tionstechnik und innerhalb dieses Bereiches auch ausschließlich auf die Segmente Software 
und IT-Dienstleistungen gerichtet. Es sind diese Bereiche, die im Fokus der Debatte über IT- 
Offshoring stehen, wohingegen die Verlagerung von Arbeit im dritten vom BITKOM definierten 
Branchensegment, dem der IT-Hardware, bereits eine lange Geschichte aufweisen kann (vgl. 
dazu z.B. Lüthje 2006). 
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Kontrolle (vgl. z.B. Boes und Baukrowitz 2002, auch Smith und McKinlay 2009) 
verstanden werden. Das Management sei angeblich nicht in der Lage, den Ar- 
beitsprozess ähnlich weitreichend zu durchdringen und zu modellieren, wie in 
anderen, weniger kreativen oder wissensintensiven Bereichen, wie z.B. der Auto- 
mobilindustrie (vgl. auch Kalkowski und Mickler 2005). Vielmehr fänden sich bei 
Tätigkeiten im IT-Bereich Formen der Arbeitskontrolle, die nach Friedman mit 
dem Begriff der „verantwortlichen Autonomie“ gefasst werden können (Fried- 
man 1977). Gekennzeichnet seien diese Formen durch den großen Handlungs- 
und Verantwortungsspielraum, der den Beschäftigten bei der Verrichtung ih- 
rer Arbeitsaufgaben gelassen wird (Alvesson 2004, Boes und Baukrowitz 2002, 
McKinlay und Smith 2009). Statt Bearbeitungsschritte kleinteilig vorzuschreiben, 
verlasse sich das Management weitgehend darauf, dass die Beschäftigten selbst 
entscheiden, wie sie ihre Arbeit effizient erledigen (u.a. Töpsch, Menez und 
Malanowski 2001, Heidenreich und Töpsch 1998). 

Voraussetzung dieser Art der Arbeitskontrolle ist Eigeninitiative der Beschäf- 
tigten, sowie deren Bereitschaft, die Ziele des Managements zu ihren eigenen 
zu machen. In der Literatur werden unterschiedliche Ansätze diskutiert, mit 
denen Unternehmen versuchen, dies sicherzustellen, seien es leistungsbezogene 
Bewertungssysteme, die das Profit-Interesse des Betriebes mit den Eigeninter- 
essen der Beschäftigten verknüpfen (Töpsch, Menez und Malanowski 2001), 
die Inszenierung von Firmenkultur (Kunda 1992), die Machtverhältnisse ver- 
schleiert, oder auch einfach der bloße Rückgriff auf die ohnehin vorhandene 
professionelle, schwerpunktmäßig arbeitsinhaltliche Motivationsstruktur von 
Hochqualifizierten (Kotthoff 1997). Gemein ist allen Ansätzen, dass es sich um 
Formen der „indirekten“ Einflussnahme handelt, die den Beschäftigten im Ar- 
beitsprozess hohe Grade der Selbstorganisation und -steuerung lässt (Voß und 
Pongratz 1998). Entsprechend wird das Selbstverständnis der hochqualifizierten 
IT-Beschäftigten häufig als das des „Kunsthandwerkers“ charakterisiert, das die in- 
tegrierten Tätigkeitsprofile, die damit verknüpften großen Verantwortungs- und 
Dispositionsspielräume sowie die in diesen Arbeitsformen grundsätzlich erfor- 
derliche Kreativität und Selbstorganisationsfähigkeit der Beschäftigten reflektiere 
(Janßen 2005; Adler 2006). Grundsätzlich werden IT-Beschäftigten aufgrund der 
spezifischen Kontrollformen hohe Primärmachtpotenziale (Crozier und Fried- 
berg 1979) zugeschrieben, die sich aus einem erheblichen impliziten Wissen über 
den Arbeitsprozess speisen, Beschäftigte schwer ersetzbar und damit ihre Jobs 
sicherer machten. 
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Glaubt man nun den Studien, die sich mit der Verlagerung von Arbeit im 
IT-Bereich - dem IT-Offshoring - beschäftigen, so hat sich diese Situation grund- 
sätzlich gewandelt. 

Zum einen straft die im Laufe der 90er Jahre einsetzende Verlagerungsdynamik 
im Bereich der IT-Dienstleistungen und der Softwareentwicklung die Annahme 
Lügen, dass sich hochqualifizierte Dienstleistungsarbeit nicht global verlagern 
lasse. Immerhin erproben auch IT-Unternehmen zunehmend die neuen Mög- 
lichkeiten der Verlagerung? und entwickeln globale Produktionsmodelle, mit 
der sowohl Lohnkostenunterschiede zwischen Regionen genutzt als auch neue 
Gruppen von Arbeitskräften erschlossen werden können. Die Beschäftigten in 
den Hochlohnregionen der kapitalistischen Wirtschaft konkurrieren dadurch 
in zunehmendem Maße auch im Bereich der hochqualifizierten Tätigkeiten mit 
Beschäftigten in den aufstrebenden Niedriglohnregionen um ihre Jobs. 

Damit scheint sich zum anderen auch das Machtverhältnis zwischen IT-Be- 
schäftigten und Management im Arbeitsprozess zugunsten des Managements 
zu verschieben. Der Grund dafür ist die Veränderung zentraler Strukturmerk- 
male der Branche, die in der Literatur häufig unter dem Stichwort der „IT- 
Industrialisierung“ gefasst werden (z.B. Walter, Böhmann und Kremar 2007; 
Boes, Kämpf und Trinks 2005; Brenner u. a. 2007). Obwohl je nach Autoren im 
Detail unterschiedliche Definitionen dessen kursieren, was unter „Industrialisie- 
rung“ gefasst wird, bzw. wie weit in diesem Bereich auf einen an den „klassischen 
Industrien“ geprägten Industrialisierungsbegriff rekurriert werden kann, so kann 
die folgende von Walter, Böhmann und Kremar (2007) vorgenommene Definition 
als weitgehend typisch für die Debatte angesehen werden: 


„Industrialisierung basiert also auf technischem und organisatorischem 
Fortschritt, ist durch Automatisierung der Produktion charakterisiert und 
führt dadurch zu signifikant sinkenden Kosten für die zentralisierte, spezia- 
lisierte und global verteilte Produktion standardisierter Produkte.“ (ebd., 
S.2; für eine etwas andere Formulierung, siehe Brenner u. a. 2007) 


Dieser Definition folgend, besteht Industrialisierung im wesentlichen in Verände- 
rungen (vorwiegend Standardisierungsprozessen) auf den Ebenen der technischen 
Grundlagen, der Produkte bzw. Leistungen und der organisatorischen Prozesse 
im IT-Bereich (vgl. Kampf 2008, $.65; Boes 2004, S.45 ff; siehe auch Sahay 2003): 


? Die neuen Verlagerungsmöglichkeiten basieren auf einer Reihe von Veränderungen im tech- 
nischen, wirtschaftlichen und politischen Bereich, die sich in den letzten Jahren durchgesetzt 
haben. Für nähere Ausführungen siehe z.B. Aspray, Mayadas und Vardi 2006, Boes 2004 oder 
Boes und Schwemmle 2004 
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Auf der technischen Ebene betrifft dies vor allem das Aufkommen und die 
Durchsetzung von (offenen) Technologiestandards hinsichtlich Programmier- 
sprachen, Netzwerkprotokollen u.ä. (Boes und Trinks 2006, $.88). Dies mache 
es in der Folge möglich, Software unabhängig der verwandten technologischen 
Plattform für eine größere Zahl von Systemen zu entwickeln und auch entspre- 
chend zu betreuen. Diese Entwicklung bringe somit einen separaten - von der 
Hardware unabhängigen - Software-Bereich überhaupt erst hervor (ebd.), indem 
Software unabhängig der eingesetzten Rechnerarchitektur entwickelt und von 
vielen Nutzern auf unterschiedlichen technologischen Plattformen eingesetzt 
werden könne. 

Die technische Standardisierung ermögliche damit in der Folge auch eine 
Standardisierung der angebotenen Produkte und Leistungen. Boes und Trinks (ebd.) 
sprechen in diesem Zusammenhang auch von der Ablösung des Paradigmas der 
Individualsoftware durch das der Standardsoftware, 


»[---] welche stets ein universales Konzept für die Lösung eines verallge- 
meinerbaren Problems enthält. Dieses Standardprodukt wird in mehreren 
Anpassungsschritten in eine Lösung für den Kunden überführt.“ (S. 89, vel. 
auch Walter, Bohmann und Kremar 2007, S. 2f) 


Die Durchsetzung des Paradigmas der Standardsoftware habe nach Ansicht der zi- 
tierten Autoren weitreichende Konsequenzen für die Akteure in der IT-Industrie. 
Zunächst beinhalte sie eine Umorientierung der Anwender. Statt benötigte IT- 
Systeme für individuelle Bedürfnisse entwickeln zu lassen, könnten diese zuneh- 
mend auf verfügbare und meist kostengünstigere Standardsoftware zurückgrei- 
fen. Dies bedeute damit auch eine Umorientierung der Anbieter von Software. 
Statt kundenindividuelle Software zu entwickeln, würden Standardprodukte 
entwickelt, die anschließend an eine große Zahl von Kunden vertrieben werden 
könnten. Schließlich entstehe durch diese Veränderungen auch ein ganz eigener 
Markt für IT-Dienstleistungsunternehmen, die sich auf die Implementierung, 
Wartung und ggf. kundenspezifische Anpassung der Standardprodukte an die 
unterschiedlichen Kundenbedürfnisse spezialisierten. Wenn die Anwender zuneh- 
mend Standardsoftware einsetzen, könnten auch Dienstleistungsunternehmen 
entsprechend standardisierte Leistungen und Lösungen anbieten. Dies bilde 
in der Folge den Hintergrund dafür, dass Anwenderunternehmen zunehmend 
vorher intern erbrachte Leistungen auch an externe Dienstleister auslagerten 
(Outsourcing), da die externen Dienstleister bei der Leistungserbringung durch 
zunehmende Spezialisierung und Standardisierung auch Skaleneffekte erzielen 
können und dementsprechend häufig kostengünstiger seien als die vormals in- 
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ternen IT-Abteilungen der Anwenderunternehmen (vgl. Taubner 2001, Brenner 
u. a. 2007). 

Die bei den Akteuren der IT-Industrie aufscheinenden Veränderungen im Zuge 
der Durchsetzung des Paradigmas der Standardsoftware, führten demnach in 
der Folge zu einer neuen, die Branche dominierenden Arbeitsteilung. Hat schon 
die Trennung von Hard- und Software-Sektor im Zuge der Standardisierung der 
technischen Grundlagen zu einer vertikalen Desintegration der die IT-Industrie 
lange Zeit dominierenden vertikal integrierten IT-Großunternehmen geführt’, 
so führe die Standardisierung der Produkte und Leistungen zu einer weiteren 
Differenzierung des Software-Sektors, mit den Herstellern von standardisierten 
Software-Produkten auf der einen und IT-Dienstleistern, welche diese Produkte 
in eine kundenspezifische Lösung überführen und zudem im Betrieb betreuen, 
auf der anderen Seite*. 

Die Standardisierung der technischen Grundlagen, sowie der Produkte und 
Leistungen biete schließlich den IT-Unternehmen (sowohl der Standardsoftware- 
Hersteller als auch den IT-Dienstleistern) die Möglichkeit, auch die eigenen 
Prozesse und Arbeitsabläufe zum Gegenstand von Rationalisierungs- und Stan- 
dardisierungsbemühungen zu machen (Boes 2004, S. 48, Kämpf 2008, S.64). 
Gemeint ist damit der Versuch, den Erstellungsprozess von Software - aber 
auch von spezialisierten Dienstleistungen - in einer neuen Art und Weise zu 
organisieren. 

Die erwartete Richtung der Reorganisationsbemühungen der Unternehmen 
ziele dabei nach Lage der Literatur zentral darauf ab, die Arbeitsprozesse z.B. 
durch standardisierte Tools und Entwicklungsumgebungen, aber auch durch 
veränderte Managementstrategien, weitreichend zu standardisieren und zu for- 
malisieren. Sei für die frühere Phase der IT-Industrie - wie ausgeführt - das Bild 
des Software-Entwicklers als „Kunsthandwerker“ prägend gewesen, so sollten 
Entwickler in industrialisierten Arbeitsprozessen eher Spezialisten sein, die mit 
klaren und robusten Prozessen Software arbeitsteilig entwickeln (Meyer 2006). 
Dieser Argumentation zufolge würden in der Folge nicht nur die für Entwickler 


> Dieser Prozess wird in der Literatur mit dem Begriff des „Wintelismus“ (Borrus und Zysman 
1997) bezeichnet. Der Begriff des Wintelismus beschreibt dabei als Wortzusammensetzung 
aus den beiden Namen „Windows“ und „Intel“ die angesprochene Trennung von Hard- und 
Softwaresektor. 

* Eine separate Dienstleistungsfunktion ist in der Form nicht neu in der IT-Industrie, jedoch wurde 
diese früher entweder als zusätzlicher Service von Großcomputerherstellern geleistet, oder von 
den Anwenderunternehmen intern durch eigene Abteilungen erbracht. Neu ist demnach ein 
separates Marktsegment mit auf diesen Bereich spezialisierten Unternehmen (vgl. Boes 2004). 
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traditionell hohen Handlungs- und Entscheidungsspielräume durch den gestiege- 
nen Grad der (globalen) Arbeitsteilung eingeschränkt (Boes 2004, auch Flecker 
und Meil 2010, Flecker und Holtgrewe 2008), sondern durch die formelle Durch- 
dringung und Zerlegung der Arbeitsprozesse mithilfe standardisierter Prozessvor- 
gaben würde die Arbeit der Entwickler auch zunehmend der direkten Kontrolle 
des Managements unterworfen, da detailliert definierte und standardisierte Pro- 
zesse häufig mit entsprechenden Kennziffern und Evaluationsmetriken hinterlegt 
seien, die es gestatteten, die Arbeitsleistung der Entwickler gänzlich anders zu 
erheben und zu bewerten, als dies vorher der Fall gewesen sei (Kampf 2008, 5.73). 
Damit wären auch die impliziten Wissensbestände der Beschäftigten über den 
Arbeitsprozess gefährdet, die die traditionell hohen Primärmachtpotenziale der 
Beschäftigten bisher begründeten und diese schwer ersetzbar machten. 

Die „Industrialisierung“ der Arbeitsabläufe verändere nach Ansicht der genann- 
ten Autoren damit nicht nur grundsätzlich die Organisation und Kontrolle von 
Arbeit in der IT-Industrie, sondern ermögliche es den IT-Unternehmen in der 
Folge auch, räumlich entfernt ausführbare Prozesse und Funktionen zu identifi- 
zieren und entsprechend aus den vor Ort ablaufenden Prozessen herauszulösen, 
zu verlagern und so u.a. Lohnkostenunterschiede zwischen unterschiedlichen 
Weltregionen zu nutzen. Waren die Bereiche der Softwareentwicklung und IT- 
Dienstleistungen damit lange Zeit geografisch vorwiegend auf die entwickelten 
Industrieländer beschränkt, so werden im Zuge der Internationalisierung da- 
mit zunehmend andere Regionen in die globalen Produktionsstrukturen der 
IT-Unternehmen eingebunden’. 

Nach Lage der Literatur dürfe jedoch kein einseitiges Kausalverhältnis zwi- 
schen Industrialisierung und Internationalisierung der IT-Industrie angenommen 
werden. Vielmehr bildeten Industrialisierung und Internationalisierung nach 
Ansicht vieler Autoren einen dynamischen Wirkungszusammenhang, in dem 
sich beide Entwicklungen gegenseitig bedingen und weiter vorantreiben. 

So wird einerseits eine weitreichende Industrialisierung in Form zunehmen- 
der Standardisierung und Formalisierung der Arbeitsprozesse als eine zentrale 
Voraussetzung für die Etablierung global verteilter Arbeitsprozesse angesehen, 
da sie die vormals ganzheitlichen Tätigkeitsprofile der Beschäftigten, die für die 
IT-Industrie lange Zeit als typisch galten, zu stärker arbeitsteiligen und speziali- 
sierten Funktionen transformiere. Dadurch komme es in den Arbeitsabläufen zu 


3 Historisch beginnt dieser Prozess durch eine Einbeziehung anderer Hochlohnregionen, wie z.B. 
amerikanische Niederlassungen europäischer IT-Unternehmen. Zunehmend werden aber vor 
allem Niedriglohnregionen als Ziel der Arbeitsverlagerung gewählt (vgl. ebd.). 
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differenzierten Rollen mit festen Zuständigkeiten in separat ablaufenden, klar 
beschriebenen und spezifizierten Prozessen (vgl. u.a. Kampf 2008, 69ff.; Boes 
2004, 126f.; Aspray, Mayadas und Vardi 2006, S.61; Sahay 2003). Erst auf dieser 
Grundlage sei es in der Folge dann auch möglich, die räumlich entfernt ausführba- 
ren Prozesse und Funktionen zu identifizieren und entsprechend aus den vor Ort 
ablaufenden Prozessen herauszulösen und zu verlagern. Zudem sei die Relevanz 
von direkter Kommunikation und face-to-face Kontakt bei standardisierten und 
vor allem auch formalisierten Arbeitsprozessen wesentlich geringer. 

Zum anderen wird umgekehrt erwartet, dass „die Realisierung von Offshoring- 
Projekten [...] Standardisierungswirkungen auf die verbleibenden Arbeitsprozes- 
se [hat] und [...] insofern ein wichtiger Treiber weiterer Standardisierungsbestre- 
bungen [ist]“ (Boes 2004, $.127; ähnlich auch Kampf 2008, S.66). 

Nach Ansicht der Vertreter der „Industrialisierungsthese“, bilden Industriali- 
sierung und Internationalisierung also eine Art „Teufelskreis“, dessen dynami- 
sche Entwicklung die Arbeitsprozesse in der II-Industrie zunehmend standar- 
disiere, formalisiere und zudem global fragmentiere. Für die IT-Beschaftigten 
bedeuten diese Entwicklungen damit potentiell einen großen Umbruch ihrer 
Arbeitssituation. Sowohl auf der Ebene der Beschäftigungsverhältnisse - als „neue 
Unsicherheitserfahrung“ (Kampf) - als auch auf der Ebene der Arbeitsorgani- 
sation - als Zunahme restriktiver Formen der Arbeitskontrolle im Zuge von 
Standardisierung und Formalisierung der Arbeitsprozesse - drohen sich zentrale 
Charakteristika einer Beschäftigung in der IT-Industrie zu verändern, die lange 
Zeit als typisch für diese Art der Arbeit angesehen wurden. 


1.2 Fragestellung der Studie 


Zweifellos lassen sich eine Reihe der in der Debatte thematisierten Entwicklun- 
gen gegenwärtig in der IT-Industrie beobachten. So befindet sich die IT-Industrie 
ganz offensichtlich in einer Phase der zunehmenden Internationalisierung ihrer 
Leistungserstellungsprozesse. Regionen in der kapitalistischen Semiperipherie, 
wie z.B. Indien und China, haben in den letzten Jahren einen sprunghaften An- 
stieg der Software-Exporte zu verzeichnen und viele der großen IT-Unternehmen 
haben mittlerweile Dependancen in unterschiedlichen Weltregionen gegründet 
und operieren damit global verteilt über verschiedene Standorte hinweg. Auch 
die Standardisierungstendenzen der technischen Grundlagen und der Produkte 
und Leistungen in der IT-Industrie, die mit dem Begriff der Industrialisierung 
angesprochen werden, sind schwerlich von der Hand zu weisende Entwicklun- 
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gen, welche die Gestalt der Branche in den letzten 20 Jahren z.T. stark verändert 
haben. 

Die Frage jedoch, ob es im Zuge der Internationalisierung der IT-Industrie 
auch zu der von den Vertretern der Industrialisierungsthese behaupteten Standar- 
disierung und Formalisierung der Arbeitsprozesse durch veränderte betriebliche 
Kontrollkonzepte kommt, ist nach wie vor offen. Das liegt zum einen daran, 
dass bisher nur wenige empirische Studien zu diesem Thema verfügbar sind (vgl. 
zu der Einschätzung auch Upadhya 2009), zum anderen aber auch daran, dass 
schon die wenigen verfügbaren Studien die behauptete Industrialisierung der Ar- 
beitsprozesse im Zuge der Internationalisierung nur sehr eingeschränkt belegen 
können. So gestehen selbst die Vertreter der Industrialisierungsthese zu, dass die 
Durchsetzung der veränderten Organisationskonzepte in den Unternehmen 


»[---] keinesfalls ein determinierter unilinearer Prozess [ist]. Vielmehr 
brechen sich die Umsetzung und die Ausgestaltung der internationalen 
Arbeitsteilung in der Praxis an betrieblichen Kräfteverhältnissen, gesell- 
schaftlichen Rahmenbedingungen und den kulturellen settings vor Ort“ 
(Kampf 2008, S.81, Hervorhebung im Original). 


Derselbe Autor konstatiert in seiner Studie dann überraschenderweise sogar, 
dass es einigen IT-Beschaftigten im Zuge der Verlagerungsbemühungen ihres 
Unternehmens durchaus gelinge, die eigene Macht- und Verhandlungsposition 
zu stärken. Die Standardisierung und Formalisierung in jenen Unternehmen sei 
nicht derart fortgeschritten, dass sie die Abhängigkeit des Managements von zen- 
tralen Akteuren aufgrund deren Stellung im Arbeitsprozess in größerem Maße 
reduzieren würde, weshalb die erfolgreiche Koordination mit den Offshore- 
Standorten noch stark an zentralen „Key-Playern“ in diesen Unternehmen hänge 
(ebd., S. 372ff). Letztlich zeigt sich somit, dass der von den Vertretern der In- 
dustrialisierungsthese unterstellte Zusammenhang zwischen Industrialisierung 
und Internationalisierung der IT-Industrie in der Realität wesentlich weniger 
zwingend und eindeutig sein könnte, als gewöhnlich behauptet wird. 

Die vorliegende Studie richtet ihren Blick daher auch genau auf diesen Zu- 
sammenhang von Industrialisierung und Internationalisierung der IT-Industrie. 
Sie geht der Frage nach, ob es durch die zunehmende Internationalisierung der 
IT- Industrie tatsächlich zu dem von den Vertretern der Industrialisierungsthese er- 
warteten weitreichenden Umbruch in den Formen der betrieblichen Kontrolle von 
IT-Arbeit kommt. Für die arbeitssoziologische Forschung ist diese Frage von be- 
sonderem Interesse, da IT-Arbeit stets geradezu als Paradebeispiel bei der Analyse 
hochqualifizierter Tätigkeiten diente und diesen Tätigkeiten generell zugeschrie- 
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ben wurde, sich eher „direkten“ Formen der Kontrolle zu sperren (siehe Kapitel 
1.1). Von daher würde ein derart umfassender Bruch in der Form der betriebli- 
chen Kontrolle von IT-Arbeit, wie ihn die genannten Autoren prognostizieren, 
das Bild von Arbeit in der IT-Industrie nachhaltig verändern. 

Für die Vertreter der Industrialisierungsthese ist die selbst festgestellte Un- 
einheitlichkeit der betrieblichen Reorganisationsbemühungen kein Grund, den 
prognostizierten Zusammenhang von Industrialisierung und Internationalisie- 
rung in Frage zu stellen. So behandelt Kämpf die noch auf die individuellen 
Selbstorganisationsfähigkeiten der Beschäftigten abzielenden Formen der Ar- 
beitsorganisation in seinen Fallunternehmen lediglich als Ausdruck „ökonomi- 
sche[n] Druck[s] und mangelnde[r] Prozessreife“, wodurch „das Management 
zu ‘hektischen’ und nicht immer systematischen Formen der Integration der 
Offshore-Standorte genötigt“ werde (Kampf 2008, S. 373). Kontrollstrategien, die 
dem Muster der „verantwortlichen Autonomie“ folgen, seien dieser Auffassung 
nach daher nur „Überbleibsel“ traditioneller Formen der Arbeitsorganisation 
und -kontrolle in den IT-Unternehmen und verwiesen auf einen Rückstand in den 
Industrialisierungsstrategien dieser Unternehmen (ebd., S. 373). Gemäß dieser 
Einschätzung kommt er dann auch zu dem Schluss, dass 


»[---] Standardisierung und Industrialisierung [...] als wesentliche Voraus- 
setzung der Internationalisierung im Bereich Software-Entwicklung und 
IT-Dienstleistungen zu gelten [haben], auch wenn es den konkreten Fall- 
unternehmen nicht ohne weiteres gelingt, diese Voraussetzung zu erfüllen.“ 


(ebd., S. 374) 


Dieser Schlussfolgerung will die vorliegende Studie widersprechen. Statt die empi- 
risch vorfindbare Varianz der Reorganisationsprozesse als (langfristig schwächer 
werdende) Abweichungen von einem die Branche dominierenden Meta-Trend 
zu deuten, soll hier argumentiert werden, dass innerhalb der IT-Industrie statt 
branchenübergreifend eindeutiger Industrialisierungstendenzen vielmehr unter- 
schiedliche Reorganisationsmodi als spezifische Strategien und Formen der (Re-) 
Organisation und Kontrolle von Arbeit zur Etablierung der neuen globalen Ar- 
beitsprozesse entstehen, die ganz unterschiedliche Folgen für die Arbeitssituation 
der Beschäftigten haben. Diese Arbeit konzentriert sich auf jene Phänomene, 
die in der bisherigen Debatte häufig vernachlässigt werden. Geht die Debatte, 
wie im vorigen Kapitel gezeigt, davon aus, dass sich die Industrialisierung in der 
IT-Industrie als branchenweit eher einheitlicher Prozess vollzieht, so bezieht diese 
Studie explizit die unterschiedlichen, in der IT-Industrie vorfindbaren Interna- 
tionalisierungswege und die in die entstehenden globalen Wertschöpfungsketten 
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eingebundenen neuen Standorte in die Analyse mit ein. Das zentrale Argument 
lautet, dass die unterschiedlichen Reorganisationsmodi und die Formen der 
Arbeitsorganisation und -kontrolle, die sie beinhalten, abhängig sind vom Wech- 
selspiel der von den Unternehmen verfolgten Internationalisierungswegen mit 
lokalen Charakteristika der Offshore-Standorte. 

Damit wird auf der einen Seite dem Umstand Rechnung getragen, dass sich 
die Verlagerung von IT-Arbeit aus den kapitalistischen Zentren an Offshore- 
Standorte in Niedriglohnregionen der kapitalistischen Semi-Peripherie in unter- 
schiedlichen Formen vollzieht, die auf unterschiedliche Geschäftsmodelle der 
beteiligten Unternehmen zurückgeführt werden können (vgl. Flecker 2006; Fle- 
cker u.a. 2007). In dieser Studie wird mit „Offshore-Outsourcing“ und „Captive- 
Offshoring“ zwischen zwei wichtigen Varianten der Verlagerung von IT-Arbeit - 
und damit der Internationalisierung der IT-Industrie - unterschieden. 

Unter „Offshore-Outsourcing“ wird das gleichzeitige Aus- und Verlagern von 
vorher intern erbrachten IT-Leistungen eines Unternehmens an einen externen 
und auf diese Tätigkeiten spezialisierten IT-Dienstleister verstanden, der seiner- 
seits dann die Leistung (zumindest z.T.) Offshore erbringen lässt. Meist handelt 
es sich bei den verlagernden Unternehmen um IT-Anwender, also Unternehmen, 
deren Kerngeschäft nicht in der Erstellung von IT-Leistungen oder -Produkten 
besteht, wie z.B. klassischerweise Banken oder Versicherungen. Auf der Seite der 
externen Dienstleister finden sich in diesem Markt einerseits die großen, amerika- 
nischen und europäischen IT-Dienstleister, wie Accenture, IBM, EDS oder auch 
T-Systems, die, nachdem sie ihre Kunden lange Zeit aus den Hochlohnregionen 
der USA oder Europas bedient haben, im Zuge der verschärften Konkurrenz an- 
gefangen haben, Offshore-Kapazitäten in ihre Leistungserstellungsprozesse einzu- 
binden. Vorreiter und zunehmend Vorbilder für die organisatorische Umsetzung 
dieses Geschäftsmodells sind gegenwärtig allerdings aufstrebende IT-Dienstleister 
aus Indien, wie z.B. TCS, Infosys und Wipro, die in den letzten Jahren durch 
enorme Umsatzwachstumsraten und spezielle Organisationsmodelle aufgefallen 
sind, und zunehmend Marktanteile in den USA und Europa erobern. 

Mit „Captive-Offshoring“ wird hingegen die räumliche Verlagerung von Arbeit 
innerhalb der Firmengrenzen des verlagernden Unternehmens gefasst. Diese Va- 
riante der Verlagerung wird als „Captive-Offshoring“ bezeichnet, weil die in ent- 
fernten Regionen gegründete Niederlassung Eigentum des Mutterunternehmens 
bleibt. Vor allem die großen amerikanischen und europäischen Standardsoftware- 
Hersteller, wie z.B. Microsoft, SAP, Oracle, Adobe, aber auch Unternehmen, 
die Software z.B. als Teil von Großmaschinen (sogen. „Embedded Software“) 
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entwickeln, unterhalten mittlerweile große Offshore-Entwicklungszentren in 
Niedriglohnregionen, in denen sie Teile ihrer Produkte entwickeln lassen. 

Die vorliegende Studie argumentiert, dass diese beiden Verlagerungsvarianten 
ganz entscheidenden Einfluss auf die entstehenden Reorganisationsmodi haben, 
weil mit dem Verlagerungsmodell weitreichende Festlegungen im Hinblick auf 
die Art der verlagerten und im Offshore-Entwicklungszentrum ausgeführten Ar- 
beiten getroffen werden. Entschieden wird damit, welche konkreten Tätigkeiten, 
mit welchen Qualifikationsansprüchen und welchen kreativen Anforderungen 
von den Unternehmen an den neuen Standorten ausgeführt werden. 

Doch es sind nicht nur diese unterschiedlichen Verlagerungsvarianten, die sich 
auf die Reorganisationsmodi von Arbeit auswirken. Wie sich zeigen wird, ist die 
Form der Reorganisation der Arbeitsprozesse zudem stark von zentralen Eigen- 
schaften des Offshore-Standortes abhängig, an dem die Tätigkeiten ausgeführt 
werden sollen. 

So berücksichtigt diese Studie auf der anderen Seite - neben den variierenden 
Internationalisierungswegen - auch den Einfluss des lokalen II-Arbeitsmarktes 
(als ein wesentliches Charakteristikum des Ziel-Standortes) auf die entstehenden 
Formen der Arbeitsorganisation und -kontrolle, weil dieser durch das lokal ver- 
fügbare Arbeitskräfteangebot auch über Möglichkeiten und Beschränkungen der 
Organisation der Arbeitsprozesse an diesen Standorten bestimmt (vgl. z.B. auch 
Athreye 2005a, S. 35). So hängt z.B. die Art der an den neuen Standorten aus- 
führbaren Tätigkeiten ganz entscheidend von der Existenz einer ausreichenden 
Zahl entsprechend qualifizierter Arbeitskräfte ab. Zudem kann das Kräfteverhält- 
nis auf dem Arbeitsmarkt auch über mögliche Kontrollpraktiken entscheiden, 
weil den Beschäftigten durch eine überhängende Nachfrage auf dem Arbeits- 
markt Machtpotenziale zufallen, etwa in Form erleichterter Jobwechsel, die eine 
anspruchsvolle Haltung in Bezug auf die Tätigkeiten möglich machen, denen 
betrieblich Rechnung getragen werden muss (Smith (2006) spricht in diesem 
Zusammenhang von „mobility power“ der Beschäftigten). Umgekehrt kann ein 
Überangebot auf dem Arbeitsmarkt helfen, bestimmte Formen der Organisation 
von Arbeit durchzusetzen, die ansonsten von den Beschäftigten nicht akzeptiert 
würden. Die Situation auf dem Arbeitsmarkt wird damit zu einem ganz eigenstän- 
digen Einflussfaktor auf die Reorganisationsbemühungen der an dem Standort 
aktiven Unternehmen. 

Die zentrale Hypothese dieser Studie lautet zusammenfassend also, dass sich in 
der IT-Industrie im Zuge ihrer Internationalisierung statt einheitlicher und gleich- 
förmiger Industrialisierungsprozesse vielmehr spezifische Reorganisationsmodi 
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identifizieren lassen, die sowohl von variierenden Internationalisierungswegen in- 
nerhalb der Branche, als auch von den Arbeitsmärkte an den Offshore-Standorten 
geprägt werden, und die - so die Hypothese weiter - unterschiedliche Formen der 
Kontrolle von Arbeit beinhalten. Abbildung 1.1 fasst den Ansatz der Studie noch 
einmal zusammen. 
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Abbildung 1.1: Reorganisationsmodi unter Einfluss von Verlagerungsvarianten 
und Arbeitsmarkt des Offshore-Standortes 


1.3 Empirisches Design und methodisches Vorgehen 


Die vorliegende Studie beinhaltet Betriebsfallstudien von zwei II-Unternehmen, 
die in unterschiedlicher Weise an der Verlagerung von IT-Arbeit von Deutsch- 
land nach Indien mitwirken. Die Beschränkung auf zwei Fälle hat den Nach- 
teil, dass keine repräsentativen Ergebnisse für die IT-Industrie erwartet werden 
können. Allerdings wird mit einem IT-Dienstleistungsunternehmen und einem 
Standardsoftware-Entwickler der Fokus der Studie auf zwei Akteure gerichtet, 
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die an der gegenwärtigen Phase der Internationalisierung der IT-Industrie in 
besonderem Maße beteiligt sind und deren Geschäfts- und Organisationsmodelle 
die Entwicklung stark prägen. Wie sich in Kapitel 2 noch genauer zeigen wird, 
beschreiten die beiden gewählten Unternehmen sehr unterschiedliche Internatio- 
nalisierungswege, die auf die jeweils verfolgten Geschäftsmodelle zurückgeführt 
werden können, und die weitreichende Konsequenzen für die entstehenden For- 
men der standortübergreifenden Arbeitsteilung haben. Die vorliegende Studie 
erlaubt durch die Beschränkung auf zwei Fälle daher zwar keine repräsentati- 
ven Aussagen zu der branchenweiten Reichweite der untersuchten Entwicklung, 
jedoch kann sie die Unterschiede in den entstehenden Reorganisationsmodi 
innerhalb der IT-Industrie anhand der intensiven Untersuchung der Formen 
der Arbeitsorganisation und -kontrolle von zwei besonders typischen Akteu- 
ren detailliert herausarbeiten. Insofern trägt die Auswahl der Fallunternehmen 
Züge eines „most different case“-Designs®. Die Intensivfallstudien bestanden 
aus leitfadengestützten Interviews mit Beschäftigten und Managementvertretern 
mit unterschiedlichen Funktionen und auf unterschiedlichen Hierarchiestufen 
von jeweils 90-120 Minuten Länge, sowie zusätzlicher Dokumentenanalyse von 
zugänglich gemachten Firmendokumenten. 


Die Fokussierung auf den Standort Indien als Untersuchungsfeld ist dem Um- 
stand geschuldet, dass Indien gegenwärtig mit Abstand der größte Standort für 
das Offshoring von IT-Arbeit ist (vgl. auch Stamm 2005). Weltweit wurde das 
Handelsvolumen von IT- und BPO’-Offshoring-Projekte schon 2005 auf ca. 40 
Mrd. US-Dollar geschätzt (Deutsche Bank Research 2005, S.3). Indien hatte zu 
diesem Zeitpunkt schätzungsweise zwei Drittel aller weltweiten und ein Drit- 
tel aller europäischen IT-Offshoring Aufträge angezogen (Forrester Research 
2004, S. 32, Upadhya und Vasavi 2006, S. 8). Die starke Zunahme der weltweiten 
Ausgaben für Offshoring-Projekte (für 2008 wird das Marktvolumen bereits 
auf 89-93 Mrd. US-Dollar geschätzt; NASSCOM 2010) sorgte - zusammen mit 


é Die beiden Fallstudien wurden im Zeitraum von 2007-2008 im Rahmen des Forschungsprojektes 
„IT-Offshoring“ erstellt, das am Soziologischen Forschungsinstitut Göttingen (SOFI) in den 
Jahren zwischen 2006 und 2009 durchgeführt wurde. Das Projekt wurde gefördert von der 
Deutschen Forschungsgemeinschaft (DFG). Der Projektleiter war Volker Wittke und das Projekt 
wurde von Nicole Mayer-Ahuja in Zusammenarbeit mit dem Autor dieser Studie bearbeitet. 

7” BPO (Business Process Outsourcing) bezeichnet eher den Bereich der IT-gestützten Dienst- 
leistungen. Gewöhnlich werden z.B. Dienstleistungen im Bereich Rechnungslegungen oder 
Mitarbeiterverwaltung zu diesen Leistungen gezählt. Da in diesen Bereichen nur mithilfe von IT 
gearbeitet wird, aber keine IT-Arbeit im engeren Sinne geleistet wird, bleibt dieser Bereich in 
dieser Studie aussen vor. 
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einer investorenfreundlichen Politik der indischen Zentralregierung und vieler 
Bundesstaatsregierungen - im vergangenen Jahrzehnt für ein beeindruckendes 
Wachstum des indischen Software und IT-Dienstleistungsbereiches: Dieser legte 
in den 1990ern teilweise über 50 Prozent jährlich zu (Upadhya und Vasavi 2006, 
S. 8ff.). Zwar nahmen die Wachstumsraten auch in Indien ab, doch selbst von 
2004 bis 2006 war immerhin noch ein jährliches Umsatzwachstum von ca. 33 
Prozent zu verzeichnen (Deutsche Bank Research 2005, S. 5; Upadhya und Vasavi 
2006, S. 8). 

Als Untersuchungsfälle wurden mit einem deutschen Standardsoftware-Her- 
steller und einem indischen IT-Dienstleister zwei unterschiedliche Varianten der 
Verlagerung von IT-Arbeit ausgewählt. Das indische IT-Unternehmen bietet seinen 
Kunden Offshore-Outsourcing Dienstleistungen. Der deutsche Standardsoftware- 
Hersteller hat eine eigene Niederlassung im indischen Bangalore gegründet und 
entwickelt dort ein Modul eines neuen Softwareproduktes („Captive Offsho- 
ring“). 

Da diese Studie explizit die Auswirkung der Verlagerung auf die Formen der 
betrieblichen Kontrolle des Arbeitsprozesses in den indischen Entwicklungszen- 
tren berücksichtigen möchte, wurden bei den Fallstudien nicht ausschließlich 
Beschäftigte im indischen Entwicklungszentrum befragt, sondern zudem Be- 
schäftigte aus den deutschen Niederlassungen, die direkt in die Kooperation mit 
den indischen Entwicklungszentren involviert sind. Auf diese Weise sollte die 
konkrete Praxis der standortübergreifenden Kooperation erfasst werden, da dies 
wichtige Erkenntnisse über die Form und den Formalisierungsgrad der globalen 
Arbeitsteilung versprach. 

Bei den untersuchten Unternehmen handelt es sich auf der einen Seite um einen 
großen indischen IT-Dienstleister, der im folgenden als ServiceTec® bezeichnet 
wird. ServiceTec ist eines der großen indischen IT-Dienstleistungsunternehmen, 
die in den letzten Jahren durch ihre enormen Wachstumsraten sowohl der Um- 
sätze als auch der Beschäftigtenzahlen aufgefallen sind. So weist ServiceTec in 
den letzten Jahren Umsatzwachstumsraten von z.T. weit über 30% auf, die Zahl 
der weltweit Beschäftigten des Unternehmens verzehnfachte sich alleine in den 
Jahren von 2002 bis 2008 annähernd. Der Standort in Bangalore ist die Fir- 
menzentrale von ServiceTec und weltweit eines der größten von Service Tecs 
Entwicklungszentren. 


8 Aus Gründen der Anonymisierung werden in dieser Studie (auch in den Zitaten) alle Namen 
durch willkürlich gewählte andere Namen oder Bezeichnungen ersetzt. 
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Auf der anderen Seite handelt es sich um einen deutschen Standardsoftware- 
Hersteller, der in dieser Studie NovoProd heißt. NovoProd unterhält bereits 
seit mehreren Jahren Niederlassungen in unterschiedlichen Weltregionen. Der 
indische Standort in Bangalore wurde Anfang der 90er Jahre eröffnet. An diesem 
Standort arbeiten mit über 3000 Beschäftigten? knapp 20% der Gesamtbeschäf- 
tigten NovoProds. 

Die Fallstudie bei ServiceTec beinhaltete Interviews mit Beschäftigten, die in 
zwei Projekten für deutsche Kunden arbeiten. Es handelte sich dabei einerseits 
um ein klassisches Wartungsprojekt und andererseits um ein Entwicklungspro- 
jekt, in dem eine individuelle Software für einen Kunden geschrieben wurde. 
Zum Zeitpunkt der empirischen Erhebung war die Entwicklungsphase bereits 
abgeschlossen und die Beschäftigten waren vor allem mit der Fehlerbereinigung 
und dem Testen der Software beschäftigt. Bei Service’ Tec wurden 22 Gespräche 
vorwiegend im indischen Mutterhaus in Bangalore! (bei der Zitation der Ge- 
sprächspartner mit SI abgekürzt) und 9 in der deutschen Niederlassung (SD) 
geführt. Auch hier wurde darauf geachtet, an beiden Standorten Beschäftigte zu 
interviewen, die in den selben Projekten arbeiten, und unterschiedliche Hier- 
archiestufen und Funktionen zu berücksichtigen (nähere Informationen zum 
Sample bei Service Tec bietet Tabelle 8.1 im Anhang, S. 291). Leider war es für 
diese Studie nicht möglich, die vor Ort direkt beim Kunden arbeitenden Beschäf- 
tigten ServiceTecs zu interviewen, da vonseiten ServiceTecs große Befürchtungen 
bestanden, dass der Kunden ein solches Vorgehen nicht gutheißen würde. In 
vielen Fällen handele es sich um Kunden, die ihr Engagement mit indischen 
IT-Dienstleistern gerne geheimhalten würden und daher eine Untersuchung in 
ihrem Unternehmen nicht dulden würden. 

Die Gespräche bei NovoProd konzentrierten sich auf ein Team, das ein neues 
Software-Produkt entwickelt. Dieses Team umfasste Beschäftigte sowohl im deut- 
schen Hauptquartier (ND), als auch im indischen Entwicklungszentrum (NI). 
Dem Standort in Bangalore oblag dabei die Erstellung eines wichtigen Moduls 
für dieses neue Produkt, weitere Module wurden u.a. in Deutschland entwickelt. 
In Deutschland konnten insgesamt 9 Interviews mit Beschäftigten in unterschied- 
lichen Projektfunktionen geführt werden. Interviewt wurden Beschäftigte, die 
in direktem Kontakt zum indischen Entwicklungszentrum stehen und eng mit 


? Diese Zahl bezieht sich auf den Zeitpunkt der Untersuchung. Bei Erscheinen dieser Studie 
wird die Zahl weiter gewachsen sein, da der Standort in der Zeit nach der Befragung personell 
verstärkt wurde. 

1 Einige Beschäftigte konnten während des Forschungsaufenthaltes leider nicht in Bangalore 
zugegen sein und wurden daher per Telefon interviewt. 
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diesem kooperieren. Auf der indischen Seite wurden 29 Gespräche mit Beschäf- 
tigten dieses Entwicklungsteams geführt. Auch hier streuen die Interviews über 
die unterschiedlichen Hierarchiestufen und Funktionen (siehe Tabelle 8.2 (S. 292) 
im Anhang für nähere Details hinsichtlich des Gesprächsprogramms). 

Die beiden Intensivfallstudien bilden die zentrale empirische Grundlage für 
diese Studie. Zur besseren Einschätzung der in diesen Studien erhobenen Infor- 
mationen wurden zusätzlich 8 Expertengesprache in weiteren IT-Unternehmen 
sowohl in Deutschland als auch in Indien geführt. Interviewt wurden dort je- 
doch ausschließlich Vertreter des Managements sowie der Personalabteilung. Dies 
diente dazu, eine „Kontrastfolie“ zu den Intensivfallstudien zu erhalten, um die 
Besonderheiten der Fälle besser einschätzen zu können. 

Neben den Interviews mit betrieblichen Akteuren wurden zudem Expertenge- 
spräche mit Vertretern aus Politik, Wissenschaft und Wirtschaft geführt, die vor 
allem dem besseren Verständnis des Phänomens IT-Offshoring galten und der 
Identifizierung relevanter Themenfelder dienten. 

Alle Interviews wurden vom Projektteam durchgeführt, digital aufgezeichnet 
und anschließend transkribiert. Die Erhebungen im indischen Bangalore wurden 
durch zwei Forschungsaufenthalte von 2 und 14 Wochen ermöglicht. Das erho- 
bene Material wurde anschließend unter Verwendung des Analyseprogramms 
„Atlas.ti“ inhaltsanalytisch ausgewertet. 


1.4 Zum Aufbau der Studie 
Die Argumentation der vorliegenden Studie gliedert sich in die folgenden Kapitel: 


In einem ersten Schritt werden die beiden Formen der Verlagerung von Ar- 
beit, die in dieser Studie im Zentrum der Aufmerksamkeit stehen - „Offshore- 
Outsourcing“ und „Captive-Offshoring“ - näher behandelt (Kapitel 2). Es wird 
gezeigt, dass die beiden Verlagerungsvarianten auf die Geschäftsmodelle der je- 
weiligen Akteure zurückgeführt werden können, die wesentliche Unterschiede 
hinsichtlich des angebotenen Produkt-, bzw. Leistungsspektrums und der Form 
der globalen Arbeitsteilung zwischen den beiden berücksichtigten Fallunterneh- 
men begründen (2.1 und 2.2). Schließlich lassen sich in den beiden Varianten 
spezifische Formen von Standardisierung als Grundlage der Internationalisierung 
bestimmen, die - so die in diesem Abschnitt explizierte Hypothese - damit auch 
unterschiedliche Reorganisationsmodi bedingen (2.3). 
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Im zweiten Schritt werden die Eigenschaften des indischen Arbeitsmarktes für IT- 
Fachkräfte behandelt (Kapitel 3). In diesem Kapitel wird gezeigt, dass der durch 
den IT-Boom auf dem indischen Arbeitsmarkt herrschende Nachfrageüberhang 
nach IT-Fachkräften für die dort aktiven IT-Unternehmen zu Problemen geführt 
hat, da die Beschäftigten in die Lage versetzt wurden, für die mittlerweile in 
Bangalore sprichwörtlichen „few Rupees“ zu einer Konkurrenzfirma zu wechseln 
(3.1 und 3.2). Für die am indischen Standort aktiven Unternehmen stellen die 
daraus folgenden hohen Fluktuationsraten und die damit verknüpften Erwar- 
tungen der Beschäftigten hinsichtlich Gehalt und Karriere eine entscheidende 
Rahmenbedingung für die Organisation ihrer Arbeitsprozesse dar. Die in diesem 
Abschnitt ausgeführte Hypothese lautet, dass diese Rahmenbedingungen berück- 
sichtigt werden müssen, wenn man die Reorganisationsbemühungen und -modi 
der Unternehmen verstehen will, die IT-Arbeit nach Indien verlagern (3.3). 


Im Anschluss an die beiden Kapitel, in denen die für zentral erachteten Einfluss- 
faktoren auf betriebliche Reorganisationsmodi im Zuge der Internationalisierung 
näher ausgeführt wurden, wird im dritten Schritt ein konzeptioneller Zugriff 
entwickelt, der den Einfluß sowohl der beiden Verlagerungsvarianten als auch des 
indischen Arbeitsmarktes auf die in den beiden Unternehmen identifizierbaren 
Reorganisationsmodi fasst (Kapitel 4). Die variierenden Reorganisationsmodi 
werden dabei als unterschiedliche Strategien der Arbeitskontrolle interpretiert 
(4.1). Dazu greife ich auf ein Untersuchungskonzept von Andrew Friedman 
zurück, das auf der mittlerweile klassischen Unterscheidung von Kontrollstrate- 
gien der „direkten Kontrolle“ und „verantwortlichen Autonomie“ beruht (4.2) 
und die Form der betrieblichen Kontrolle als strategische Gestaltung zentraler 
Aktivitätsfelder durch das Management fasst (4.3). 


Auf diese konzeptionellen Überlegungen folgen die beiden in dieser Studie durch- 
geführten Fallstudien in je einem separaten Kapitel (Kapitel 5 und 6). Das Ziel 
der Fallstudien besteht darin, den in den vorausgehenden Kapiteln in Form von 
Hypothesen skizzierten Zusammenhang von spezifischen Internationalisierungs- 
wegen, indischem Arbeitsmarkt und daraus resultierenden variierenden Reorga- 
nisationsmodi empirisch zu belegen und näher auszuführen. Beide Fallstudien 
gliedern sich - nach einem jeweils kurzen Unterkapitel zur Charakteristik des 
Unternehmens und der Rolle des indischen Entwicklungszentrums im globalen 
Geschäftsmodell (5.1/ 5.2, bzw. 6.1/ 6.2) - entsprechend der im Konzeptionska- 
pitel vorgestellten Operationalisierung des Kontrollbegriffs (5.3bzw. 6.3). Jede 
Fallstudie endet mit einer kurzen Zusammenfassung der Ergebnisse (5.4/ 6.4). 
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Zum Abschluss (Kapitel 7) werden die in den Fallstudien identifizierten Reor- 
ganisationsmodi noch einmal gegenübergestellt und die zentralen Befunde der 
Studie zugespitzt zusammengefasst (7.1 und 7.2). Die Studie schießt mit einigen 
Gedanken zu offenen Fragen und weiterem Forschungsbedarf (7.3). 


2 Variierende 


Internationalisierungswege im 
IT-Bereich 


Die zentrale Hypothese dieser Studie lautet, dass sich in der IT-Industrie weniger 
eine gleichförmige Industrialisierung als vielmehr unterschiedliche Reorganisati- 
onsmodi im Zuge ihrer zunehmenden Internationalisierung identifizieren lassen, 
die unterschiedliche Formen der betrieblichen Kontrolle begründen. Diese Reor- 
ganisationsmodi, so die These weiter, sind in ihrer Form durch das Wechselspiel 
zwischen den variierenden Internationalisierungswegen in der IT-Industrie und 
dem Arbeitsmarkt an den Ziel-Standorten bestimmt. 

In diesem Kapitel soll gezeigt werden, dass sich mit „Offshore-Outsourcing“ 
und „Captive Offshoring“ zwei unterschiedliche Varianten der Internationali- 
sierung in der IT-Industrie identifizieren lassen, die sich aus einem speziellen 
Produkt- bzw. Leistungsspektrum und einem damit verknüpften Geschäftsmo- 
dell der beteiligten Unternehmen ergeben und die jeweils eine bestimmte Form 
der globalen Arbeitsteilung und Beziehung der miteinander in Beziehung gesetz- 
ten Standorte beinhalten. In diesen beiden Internationalisierungswegen lassen 
sich Unterschiede in der Intensität und Form der Standardisierung und Forma- 
lisierung der zugrundeliegenden Arbeitsprozesse festmachen, die - so die hier 
ausgeführte Hypothese - unterschiedliche Reorganisationsmodi in den Unter- 
nehmen begründen. 


2.1 Das „Global Delivery Model“ der IT-Dienstleister 


Die erste Variante der Internationalisierung in der IT-Industrie, die in diesem 
Kapitel in ihrer Wirkung auf den zugrundliegenden Reorganisationsmodus nä- 
her bestimmt werden soll, ist das „Offshore-Outsourcing“. Unter Offshore- 
Outsourcing werden Verlagerungsprozesse verstanden, die sowohl organisati- 
onsübergreifende Aus- (Outsourcing) als auch regionale Verlagerungsprozesse 
(Offshoring) beinhalten (vgl. Aspray, Mayadas und Vardi 2006, S.45f.). 
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Die organisationsübergreifende Verlagerung besteht darin, dass von Kunden- 
unternehmen vorher intern durch die eigenen IT-Abteilungen erbrachte IT- 
Funktionen an einen auf diese Funktionen spezialisierten externen IT-Dienst- 
leister ausgelagert werden (Outsourcing)!. 

Lange Zeit wurde dieses Outsourcing-Geschäft von den großen westlichen IT- 
Dienstleistungsunternehmen (wie z.B. IBM, Accenture oder EDS) dominiert, die 
am selben Standort ansässig waren wie die Kundenunternehmen. Diese Form des 
Outsourcings beinhaltete zunächst also kaum oder nur in geringem Umfang auch 
eine räumliche Verlagerung der Tätigkeiten von Hoch- in Niedriglohnregionen 
(vgl. Boes 2004, S.92). 

Diese Situation ändert sich jedoch, seit mit den indischen TT-Dienstleistern 
ein neuer Akteur das Geschäftsfeld betritt”. Diese - gemeint sind vor allem die 
„5 Großen“ der indischen IT-Industrie: TCS, Infosys, Wipro, Mahindra Satyam 
und HCL? - kombinierten als erste systematisch das organisationsübergreifende 
Outsourcing von IT-Leistungen mit der Nutzung von Offshore-Standorten in 
Niedriglohnregionen, fügten der organisatorischen also eine räumliche Verlage- 
rung hinzu (vgl. Dossani 2007, S. 223). Dadurch erreichen diese Unternehmen 
erheblich reduzierte Kosten mit denen sie die westlichen IT-Dienstleister un- 
ter Druck setzen und in den letzten Jahren zunehmend Marktanteile erobern 
konnten (vgl. in der Einschätzung z.B. auch Singh 2005, S. 811). So wurde den 
indischen IT-Dienstleistern bereits 2005 zugeschrieben, ein Fünftel des weltwei- 
ten Marktes für „Custom Software“, d.h. die Anpassung oder Entwicklung von 
Erweiterungen auf der Basis von Standardsoftware, abgedeckt zu haben (Athreye 
20052). 

In der Folge gehen auch die großen westlichen IT-Dienstleister dazu über, 
Offshore-Kapazitäten in ihre Wertschöpfungsketten zu integrieren, um ihre 
Kosten zu reduzieren. So haben alle großen Dienstleister mittlerweile Offshore- 
Entwicklungszentren mit teilweise erheblichen Beschäftigtenzahlen u.a. in Indien 
gegründet*. Doch obwohl damit auch die westlichen IT-Dienstleister das Out- 


1 Sicher erbringen IT-Dienstleister z.T. auch Leistungen für andere IT-Unternehmen, jedoch stellt 
die Verlagerung an externe Dienstleister bei reinen [T-Unternehmen eher die Ausnahme dar 
(vgl. Boes 2004, S.77f, Kampf 2008, 5.43) 

? Zur Internationalisierung der indischen IT-Dienstleister siehe auch Niosi und Tschang (2009); 
sowie Fortanier und Tulder (2009). 

3 „Groß“ bezieht sich in diesem Zusammenhang vor allem auf die enormen Beschäftigtenzahlen je- 
ner Unternehmen: Laut Hackmann (2010) beschäftigt TCS gegenwärtig (2010) weltweit 140.000 
Beschäftigte, Infosys 115.000, Wipro 110.000, HCL 62.000 und Mahindra Satyam 29.000. 

* IBM beschäftigt z.B. angeblich mittlerweile über 100.000 Angestellte in Indien, Accenture 50.000 
und Capgemini 23.000 (ebd.). 
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sourcing mit dem Offshoring kombinieren, gelten nach wie vor die indischen 
Dienstleister als Vorreiter und Leitbilder bei der Entwicklung dieses neuen glo- 
balen Verlagerungsmodells im Bereich der IT-Dienstleistungen (vgl. Athreye 
2005b, Boes u. a. 2007, auch Pohl und Onken 2003). Als „early adopters“ haben 
sie eine Nische der zunehmend globalen IT-Industrie besetzt und sich auf dieses 
Branchen-Segment, die Bereitstellung von Offshore-Dienstleistungen spezialisiert 
(Dossani 2007, $.225). Aus diesem Grund konzentriert sich diese Arbeit zur 
Untersuchung der Reorganisationsmodi bei „Offshore-Outsourcing“ auf einen 
indischen IT-Dienstleister. 

Der Vorteil der indischen IT-Dienstleister war und ist, dass diese ihre indischen 
Entwicklungszentren von Anfang an°als Offshore-Komponente in ihr auf den 
globalen - wenn auch anfänglich fast ausschließlich amerikanischen - Markt 
ausgerichtetes Geschäftsmodell eingebunden haben. So entwickelten sie früh 
tragfähige Produktionsprozesse und -strukturen, wohingegen die etablierten 
großen europäischen und amerikanischen IT-Dienstleister ihre Prozesse erst 
an die neuen Erfordernisse globaler Arbeitsteilung anpassen müssen, mit allen 
Rigiditäten und Konflikten, die mit der Umgestaltung der internen Arbeitsabläufe 
einhergehen (siehe Boes u. a. 2007, S.29). 


Das von den indischen Dienstleistern entwickelte - und zunehmend von den 
westlichen IT-Dienstleistern kopierte - Geschäftsmodell wird in der Literatur 
häufig als „Global Delivery Model“ bezeichnet (siehe z.B. Upadhya 2009 oder 
auch Boes u. a. 2007). Wesentliche Eigenschaften dieses Geschäftsmodells sind 
zum einen die spezielle Form der globalen Arbeitsteilung und zum anderen die 
konsequente Prozessorientierung (vgl. ebd., Lema und Hesbjerg 2003, Mayer- 
Ahuja 2011, Athreye 2005b), die damit auch einen ganz speziellen Modus der 
Organisation der Arbeitsprozesse begründen. 

Das „Global Delivery Model“ verbindet Vertriebsniederlassungen am Ort 
des Kunden (häufig auch Frontend- genannt) mit sich offshore befindlichen Ent- 
wicklungszentren (Backend) und beruht somit auf einer konsequenten Trennung 
der kundennah und den auch aus der Entfernung zu erbringenden Leistungen 
(vgl. Kampf 2008, S. 44, Boes u. a. 2007). Dies bedeutet, dass der IT-Dienstleister 
mit einer Niederlassung am Ort des Kunden präsent ist, und von dort aus (ne- 


5 Als Anfang wird hier der Moment verstanden, als die indischen IT-Dienstleistungsunternehmen 
ihr Geschäftsmodell von dem die Anfänge der indischen IT-Industrie dominierenden Body- 
Shopping-Modell auf die Offshore-Erbringung von IT-Dienstleistungen umstellten. Ausführ- 
lichere Erläuterungen zu diesen Veränderungen finden sich bei u.a. bei Athreye 2005a,bund 
Dossani 2007. 
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ben Sales- und Marketing-Aktivitaten) die Tatigkeiten bearbeitet, fiir die enger 
Kundenkontakt nötig ist. So finden sich in diesen Niederlassungen vor allem 
die beratungs- und kommunikationsintensiven Tatigkeiten, wie z.B. strategische 
Beratungsleistungen, oder - wenn es um die Entwicklung kundenspezifischer 
Software geht - das Design und die Anforderungsanalyse. 

Komplementär zu diesen Niederlassungen am Standort des Kunden (also gegen- 
wärtig noch schwerpunktmäßig in den westlichen Industrieländern) beinhaltet 
das Modell Entwicklungszentren in Offshore-Regionen. Liegt der Schwerpunkt 
der Aktivitäten der Onsite-Niederlassungen im Bereich der kommunikations- 
und beratungsintensiven Tätigkeiten, so entfallen auf die Offshore-Entwicklungs- 
zentren die eher personal- und arbeitsintensiven Tätigkeiten wie das Codieren 
und das Testing der zu entwickelnden oder zu wartenden Applikation (vgl. auch 
Heeks 1995, S. 371, Upadhya und Vasavi 2006, S.16). 

Doch es sind nicht nur die konsequente Verknüpfung von Onsite- und Off- 
shore-Kapazitaten und die darin begriindete Form der globalen Arbeitsteilung, 
die das „Global Delivery Model“ ausmachen. Vielmehr betonen mehrere Autoren 
explizit die ausgeprägte Prozessorientierung als zentrales Merkmal der indischen 
IT-Dienstleister (vgl. Boes u. a. 2007, Athreye 2005b). Unter Prozessorientierung 
werden dabei stark formalisierte und standardisierte Geschäftsprozesse verstan- 
den. Dies beinhaltet, dass für die Erbringung der unterschiedlichen Leistungen 
jeweils standardisierte Prozessbeschreibungen definiert werden. In diesen Prozess- 
beschreibungen sind dann die nötigen Schritte der Leistungserbringung detailliert 
vorgeschrieben. Eine Prozessbeschreibung enthält dementsprechend z.B. Informa- 
tionen über die am Prozess beteiligten Rollen und deren genaue Zuständigkeiten 
sowie die in jedem Arbeitsschritt zu leistenden Tätigkeiten. Zudem beinhalten 
sie häufig klare Vorgaben für die einzelnen Tätigkeiten, wie z.B. Vorlagen für 
die Protokollierung von Kundengesprächen (Die Prozessbeschreibungen werden 
bei der späteren Falldarstellung des indischen IT-Dienstleisters noch ausführlich 
behandelt). 

Die Prozessorientierung der IT-Dienstleister wird schon durch das von ihnen 
bereitgestellten Leistungsspektrum und das damit zusammenhängende Ertrags- 
modell gefördert (vgl. auch Flecker u. a. 2007, $.139). IT-Dienstleister erbringen 
schwerpunktmäßig Leistungen, die zuvor aus den Abläufen der Kundenunter- 
nehmen herausgelöst wurden. Ihr Leistungsspektrum reicht dabei von Beratungs- 
leistungen über Implementierungs- und Systemintegrations-Projekte bis hin zu 
Wartungs- und Hosting-Projekten. Zumeist handelt es sich dabei um relativ stark 
standardisierte IT-Funktionen, die zudem häufig wiederkehren. So beinhaltet 


Das „Global Delivery Model“ der IT-Dienstleister 37 


z.B. die firmenweite Installation einer neuen Windowsversion in vielen Orga- 
nisationen zum größten Teil dieselben Arbeitsschritte, so dass diese von den 
IT-Dienstleistern dementsprechend leicht standardisiert und modelliert werden 
können. Und auch die Anpassung eines Standardproduktes, wie z.B. einer SAP- 
Lösung, an unterschiedliche Unternehmensumwelten hat eine überschaubare 
Zahl von Varianten. Für die IT-Dienstleister schafft dies eine Möglichkeit, sich 
auf bestimmte, standardisierte IT-Leistungen spezialisieren zu können und damit 
auch Skalenerträge zu erzielen. Grundlage dessen ist aber die klare Standardi- 
sierung und auch Formalisierung der zugrundeliegenden Arbeitsprozesse, die 
eine wiederholbare und möglichst effiziente Durchführung der jeweiligen Pro- 
jekte erlaubt (vgl. auch ebd., S. 85ff.). Im Zentrum der Aufmerksamkeit der 
IT-Dienstleister stehen daher nicht die konkreten Projekte, sondern vielmehr 
die jeweils für ein Projekt auszuführenden Prozesse und die dazu nötigen Auf- 
wände (Boes u. a. 2007, S.26f:). Im Endeffekt besteht ein jeweils auszuführendes 
Projekt damit aus dem Ablauf einer bestimmten Zahl miteinander kombinierter 
Prozesse. 


Diese Orientierung an standardisierten Prozessen statt an jeweils unterschiedli- 
chen konkreten Projekten, wird durch das Ertragsmodell von IT-Dienstleistern 
noch zusätzlich verstärkt. Die an IT-Dienstleister ausgelagerten IT-Funktionen 
können aufgrund ihres standardisierten Charakters grundsätzlich von vielen 
Dienstleistern in vergleichbarer Qualität erbracht werden. Demnach konkurrie- 
ren IT-Dienstleister bei der Vergabe von Kundenaufträgen in erster Linie über 
die Preise und die Verlässlichkeit der Leistungserbringung. 

Zur Festlegung der Preise haben sich im Bereich der IT-Dienstleistungen in 
den letzten Jahren vor allem aufwandsbezogene Ertragsmodelle in Form von 
sogen. „Service Level Agreements“ (SLA) herauskristallisiert (Flecker u. a. 2007; 
Taylor 2010). Dabei handelt es sich um vertragliche Vereinbarungen zwischen 
den Anbietern von Dienstleistungen und deren Kunden, in denen die Art der 
zu liefernden Leistung möglichst detailliert beschrieben, in unterschiedlichen 
Kategorien, z.B. nach Art der Teilleistungen, gefasst und dann entsprechend 
auch preislich bestimmt wird. Ferner sind in solchen Vereinbarungen häufig die 
Zeiträume der Bearbeitung, Qualitätsstandards, Eskalationsstufen und entspre- 
chende Verantwortlichkeiten zwischen den Parteien geregelt. 

Die SLA’s beinhalten häufig umfangreiche Regelungen bzgl. der zu liefernden 
Leistung und greifen damit teilweise auch weit regelnd in die Arbeitsabläufe der 
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Dienstleister ein, indem bestimmte Vorgehensmodelle oder Verfahren vertraglich 
festgelegt werden®. Ein kleines Beispiel veranschaulicht diesen Punkt: 


Der in dieser Arbeit untersuchte indische IT-Dienstleister ServiceTec hat- 
te in einem Wartungsprojekt permanent Auseinandersetzungen mit dem 
Kunden. Hintergrund war, dass die von Service Tec zu wartende - aber 
nicht selbst entwickelte - Applikation diverse Fehler aufwies, die ein rei- 
bungsloses Funktionieren nahezu unmöglich machten. Dementsprechend 
hoch war der Wartungsaufwand für ServiceTec. Nun wollte der Kunde 
die identifizierten Fehler im Rahmen des mit Service Tec abgeschlossenen 
Wartungsvertrages korrigieren lassen. Service Tec verweigerte dies jedoch 
mit dem Hinweis, dass es sich bei dieser Tätigkeit um einen ganz anderen 
Prozess (Debugging statt Maintenance) mit anderen Tagessätzen handele. 
Dementsprechend sei zwar das Korrigieren der Folgefehler der Applikation 
vom Wartungsvertrag abgedeckt, das Ausbessern der Applikation selbst 
aber nicht. Diese Art von Konflikt sei nach Angaben von Beschäftigten bei 
Service Tec durchaus typisch für ihre Projekte. 


Dieses kleine Beispiel verdeutlicht die Konsequenzen des im Bereich der IT- 
Dienstleistungen dominierenden Ertragsmodells. Die SLA’s forcieren die Stan- 
dardisierung und Formalisierung der Arbeitsprozesse, weil die für den Kunden 
erbrachten Leistungen möglichst genau in einzeln abrechenbare Einheiten zerlegt 
werden müssen (vgl. auch Flecker u. a. 2007, $.97). Die von den IT-Dienstleistern 
implementierten Prozessmodelle mit ihren stark standardisierten und formali- 
sierten Abläufen bieten ihnen dabei die Möglichkeit, die nötigen Arbeitsschritte 
der Leistungserbringung für den Kunden (meist schon im voraus) detailliert 
auszuweisen und somit den Gesamtaufwand leichter einschätzbar zu machen. 


Dies ist auch der Grund, warum IT-Dienstleister stärker als andere IT-Firmen auf 
internationale Zertifizierungen der Leistungserbringungsprozesse wie CMMI, 
1509000 oder Six-Sigma - um nur einige zu nennen - setzen. 

Diese Zertifikate dienen einerseits als Werbung gegenüber Kunden, denen 
mit der erfolgreichen Zertifizierung Qualität und Effizienz in der Projektab- 
wicklung demonstriert werden soll. In einigen Bereichen stellt eine erfolgreiche 
Zertifizierung, z.B. nach CMMI’, bereits eine notwendige Voraussetzung dar, 


€ Vgl. Flecker u.a. 2007, ganz ähnlich ist dies auch im Bereich der Call-Center (vgl. Taylor 2010) 
7 „Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmo- 
dellen für unterschiedliche Anwendungsgebiete - derzeit für die Produktentwicklung, den 
Produkteinkauf und die Serviceerbringung. Ein CMMI-Modell ist eine systematische Aufberei- 
tung bewährter Praktiken, um die Verbesserung einer Organisation zu unterstützen“ (Wikipedia 
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um überhaupt an bestimmte Aufträge zu kommen, da sie von den Kunden 
als Qualitätsausweis der Leistungserbringung eingefordert wird. Die indischen 
IT-Dienstleister sind auch in dieser Hinsicht Vorreiter, denn gerade sie hatten 
anfänglich mit erheblichen Vorbehalten der Kunden gegenüber der von ihnen 
gelieferten Qualität zu kämpfen. Die indischen IT-Dienstleister versuchten diesen 
Zweifeln durch erfolgreiche Zertifizierungen zu begegnen. So kamen im Jahr 
2003 von den 80 nach CMMI Level 5 zertifizierten Unternehmen 60 aus Indien 
(Deutsche Bank Research 2005, S.6). 

Doch auch wenn eine wichtige Funktion der externen Zertifizierung in Kun- 
denwerbung besteht, unterstützt die erfolgreiche Implementierung dieser Stan- 
dards auch die Standardisierung und Formalisierung der Arbeitsprozesse in den 
Unternehmen. Schließlich sind die Prozessmodelle, unabhängig von dem Grund 
ihrer Einführung, auch real wirksam, indem sie helfen, die Arbeitsprozesse in 
einzelne, einfacher zu beherrschende und abrechenbare Teilschritte zu zerlegen, 
und es zudem erlauben, die Befolgung der Prozesse mit integrierten Kennzahlen 
zu messen (für eine kritische Auseinandersetzung mit den Prozessmodellen in 
Bezug auf die Arbeitsprozesskontrolle, siehe Prasad 1998). 

Die vielfach bemerkte „Zertifizierungswut“ (ebd.) der indischen IT-Dienst- 
leister und die starke „Prozessorientierung“ können daher als ein integraler Be- 
standteil des „Global Delivery Models“ der indischen IT-Dienstleister verstanden 
werden - sie sind seine Voraussetzung und seine Konsequenz zugleich. 


2.2 Die Herausbildung verteilter Entwicklungsmodelle 
bei Software-Herstellern 


Die andere Form der Verlagerung von IT-Arbeit, die in dieser Arbeit behandelt 
wird, ist das „Captive-Offshoring“. Unter „Captive-Offshoring“ werden Verla- 
gerungsprozesse verstanden, die sich innerhalb der organisatorischen Grenzen 
des verlagernden Unternehmens vollziehen. Konkret handelt es sich dabei um 
Verlagerungen von IT-Arbeit an eine dem Unternehmen eigene Niederlassung 
(„captive“) in einer Niedriglohnregion. 


2010b). Die Entwicklung begann 1986 auf Initiative des US-Verteidigungsministeriums am Soft- 
ware Engineering Institute (SEI) an der Carnegie Mellon University/Pittsburgh, welches dem 
US-Verteidigungsministerium untersteht. Eine erste Version des CMMI wurde 1991 veröffent- 
licht, diese wurde und wird seitdem stetig weiterentwickelt (für nähere Informationen, siehe 
auch Herbsleb u.a. 1997). 
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Die zentralen Akteure dieser Verlagerungsvariante sind Unternehmen, die in 
ihren Offshore-Entwicklungszentren Produktentwicklung betreiben (vgl. Upadh- 
ya und Vasavi 2006). Dies können auf der einen Seite Standardsoftware-Hersteller 
sein, die Teile ihrer Softwareprodukte® in Niedriglohnregionen entwickeln lassen, 
wie z.B. Adobe, Microsoft, Oracle. Auf der anderen Seite finden sich jedoch auch 
Unternehmen, die Software als Teil anderer nicht IT-spezifischer Produkte, wie 
z.B. Waschmaschinen entwickeln (sogen. „embedded software“). So sind auch 
Firmen wie Siemens, Bosch u.a. seit Jahren mit eigenen auf Softwareentwicklung 
spezialisierten Niederlassungen in Niedriglohnregionen wie Indien präsent. 

Diese Form der Verlagerung unterscheidet sich in zweierlei Hinsicht von der 
Verlagerung nach dem Muster des Offshore-Outsourcing: 


1. Die Beschäftigten in den Offshore-Entwicklungszentren erbringen keine 
Leistungen für externe Kunden, sondern sind in die Produktentwicklung 
des westlichen Mutterunternehmens eingebunden. 


2. Kundenkontakt findet bei Produkt-Herstellern zumeist lediglich am Ende 
der Produktion über den Vertrieb des Produktes statt. Zwar unterhal- 
ten einige große Software-Hersteller zudem strategische Partnerschaften 
zu Unternehmen, mit denen über zukünftige Produktinnovationen und 
Anforderungen an die zu entwickelnde Software beraten wird, und die 
auch meist für einen Testeinsatz von Prototypen und Betaversionen der 
Software herangezogen werden, jedoch findet der Produktionsprozess der 
Software-Produkte im engeren Sinne unabhängig von konkreten Kunden- 
beziehungen statt (vgl. ebd., S.20). 


Dementsprechend kreisen die Verlagerungsstrategien von Produkt-Herstellern 
auch nicht um die Trennung von kundennah und kundenfern zu erbringenden 
Tätigkeiten, wie es für IT-Dienstleister charakteristisch ist. Die Verlagerungs- 
strategien von Produkt-Herstellern sind vielmehr produkt-zentriert, d.h. das 
Produkt wird in sogen. „verteilter Entwicklung“ hergestellt. Grundlage eines 
solchen Modells sind modulare Produkt- und Prozessarchitekturen, die es erlauben, 
das Produkt in verschiedenen Modulen parallel an verschiedenen Standorten 
entwickeln zu lassen. Modulare Produkt- und Prozessstrukturen basieren auf 
einem Produktionsprozess, der aus vielen unterschiedlichen Teilen besteht, deren 


8 z.B. eine Standardapplikation, die direkt einsatzfähig ist oder mit unterschiedlich umfangreicher 
Anpassung bei den Kunden installiert werden kann (wie z.B. Microsofts bekanntes Bürosoftware- 


Paket) 
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Schnittstellen jedoch klar und eindeutig spezifiziert sind, um die anschließende 
problemlose Reintegration im Produkt zu gewährleisten. 


Im Gegensatz zum Offshore-Outsourcing von IT-Dienstleistungen kann bei 
Captive-Offshoring allerdings gegenwärtig (noch?) nicht von einem eindeutig 
dominierenden Offshoring-Modell ausgegangen werden. Vielmehr befinden sich 
die Akteure gegenwärtig in einer Art Experimentierstadium, in dem nach dem 
für sie richtigen Modell gesucht wird (Boes u. a. 2007, S.12ff.; vgl. auch Flecker 
u. a. 2007, S.47ff.). So begründen modulare Strukturen und unternehmensinterne 
Arbeitsteilung noch keinen „best way“ der internen Verlagerung, wie Flecker 
u.a. (ebd., S. 62) zu recht bemerkt: 


„However, it is both possible to hand off modules or ‘black boxes’ of sub- 
(projects) (a matter of longer-term collaborations) or smaller, circumscribed 
or standardized tasks.“ 


So wurden die Offshore-Entwicklungszentren von den Unternehmen anfänglich 
oft nur dafür genutzt, Standardprodukte zu lokalisieren, d.h. z.B. betriebswirt- 
schaftliche Softwarepakete an länderspezifische Steuerregelungen anzupassen 
(Aspray, Mayadas und Vardi 2006, S.136f.; Boes u.a. 2007, S.10f.) oder relativ 
einfache Programmier- und Codiertätigkeiten zu erledigen. Auch später bestehen 
bei vielen Unternehmen Strukturen fort, die diesem Muster folgen. Nach Boes 
kann dieses Vorgehen als Etablierung einer „verlängerten Werkbank“ bezeichnet 
werden. Im Fokus stehen 


„gut spezifizierte Aufgabenstellungen auf einem vergleichsweise einfachen 
Komplexitäts- und Technologieniveau mit geringer strategischer Bedeutung 
für das Unternehmen.“ (Boes 2004, S.97) 


Dieser Ansatz der Verlagerung betrifft also lediglich die Schritte der Softwareent- 
wicklung, die gemeinhin als besonders leicht zu verlagern gelten, wie das reine 
Codieren und Testen der Applikation. Dieses Vorgehen impliziert auch eine glo- 
bale Arbeitsteilung zwischen Standorten in Bezug auf planende und ausführende 
Tätigkeiten. Die anspruchsvollen, planenden Tätigkeiten der Konzeption und 
des Designs verbleiben bei diesem Modell allerdings meist an den westlichen 
(Heimat-) Standorten der Unternehmen (vgl. auch Flecker u. a. 2007, $.50), wo- 
hingegen die in Niedriglohnregionen lokalisierten Entwicklungszentren klar 
spezifizierte, wenig komplexe Arbeitspakete zugewiesen bekommen. 
Gegenüber der Verlagerung nach dem Muster der „verlängerten Werkbank“ 
gibt es jedoch zunehmend auch andere Formen der Verlagerungen in diesem Be- 
reich. So haben einige der großen Unternehmen, als mit zunehmender Erfahrung 
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mit verteilter Entwicklung die Zuversicht in die eigenen Fähigkeiten stieg, den 
Schritt gewagt, auch komplexe Tätigkeiten Offshore erledigen zu lassen (Farrell 
u. a. 2005, $.204f.). Dieses Vorgehen beinhaltet im wesentlichen den Aufbau „ei- 
gener Produktionsintelligenz“ (Boes 2004, 5.97) und die Vergabe auch strategisch 
wichtiger und fachlich anspruchsvoller Arbeitspakete an die Entwickler an den 
neuen Standorten. Diese Form der Verlagerung findet eher netzwerkförmig statt 
und setzt auf modulare Strukturen mit hohen Interdependenzen der einzelnen 
Standorte. Dadurch werden die neuen Standorte zunehmend auch mit planenden 
und konzeptionellen Verantwortlichkeiten betraut. 


Im Bereich des Captive-Offshoring kann daher zwar gegenwärtig noch nicht 
in dem Maße von einem Leitbild in Bezug auf ein globales Verlagerungsmodell 
ausgegangen werden, wie es im Bereich des Offshore-Outsourcing der Fall ist und 
es lassen sich daher noch wichtige Unterschiede in dem Grad feststellen, in dem 
die neu eröffneten Standorte Verantwortung für strategische Entscheidungen 
übernehmen und welche Arten von Tätigkeiten dementsprechend dort geleistet 
werden. Jedoch lässt sich feststellen, dass viele Unternehmen in den letzten Jahren 
dazu übergegangen sind, die Offshore-Standorte stärker in die entstehenden 
globalen Produktionsnetzwerke einzubinden und folglich auch mit strategisch 
wichtigeren Aufgaben zu betrauen (vgl. Flecker und Holtgrewe 2008). 


Diese Studie konzentriert sich zur Untersuchung der Reorganisationsmodi in 
diesem Bereich mit NovoProd auf eine besonders avancierte Form des Captive- 
Offshoring, da NovoProd in seinem indischen Entwicklungszentrum bereits 
hochwertige Tätigkeiten mit hoher strategischer Bedeutung für den Unterneh- 
menserfolg bearbeiten lässt. Diese Festlegung schränkt die Aussagekraft der 
gewonnen Ergebnisse zwar ein, stellt aber in diesem Zuschnitt gerade im Ver- 
gleich zum Bereich des Offshore-Outsourcing einen interessanten Kontrast dar. 
Denn gerade in dieser Variante des Captive-Offshoring treten die Unterschiede 
zwischen den beiden Verlagerungsvarianten und zwischen den zugrundeliegen- 
den Reorganisationsmodi besonders deutlich hervor. Es kann demnach gezeigt 
werden, wie unterschiedlich sich die Reorganisation der Arbeitsprozesse in den 
beiden berücksichtigten Konstellationen darstellen kann und welch unterschied- 
liche Folgen dies für die Form der Kontrolle von Arbeit hat. 
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2.3 Internationalisierungswege und 
Reorganisationsmodi 


Laut der Hypothese dieser Studie gehen die beiden skizzierten Varianten der 
Verlagerung und der damit einhergehenden Internationalisierung der Produktion 
mit unterschiedlichen Modi der Reorganisation der zugrundliegenden Arbeitspro- 
zesse einher, die im Zusammenspiel mit dem indischen Arbeitsmarkt auch die 
Form der Kontrolle von Arbeit an den indischen Offshore-Entwicklungszentren 
prägen. 

Auch wenn die genaue Analyse der Formen der Arbeitskontrolle in den spä- 
teren Kapiteln folgt, können an dieser Stelle doch bereits aus der Analyse der 
Verlagerungsvarianten erste Erkenntnisse darüber gewonnen werden, wie sich 
die beiden näher beschrieben Varianten der Verlagerung auf die Form der Reor- 
ganisation der Arbeitsprozesse auswirken. Wie bei der Darstellung der Debatte 
über die Industrialisierung der IT-Industrie bereits erläutert (Kapitel 1.1.) wird 
die Industrialisierung von IT-Arbeit vor allem als zunehmende Standardisierung 
und Formalisierung der Arbeitsprozesse definiert. Anhand der in den beiden 
vorhergehenden Unterkapiteln erläuterten Unterschiede der Verlagerung und der 
damit zusammenhängenden Geschäftsmodelle der Akteure kann gerade in dieser 
Hinsicht ein wesentlicher Unterschied konstatiert werden. So kann in Bezug 
auf Offshore-Outsourcing und Captive-Offshoring mit Mayer-Ahuja (2011, S.69) 
konstatiert werden, dass es sich im Bereich der IT-Dienstleistungen in erster Li- 
nie um Prozess-Standardisierung handelt, wohingegen Produkt-Hersteller primär 
Produkt-Standardisierung betreiben. 


Das Geschäftsmodell der - gerade indischen - IT-Dienstleister ist extrem pro- 
zessorientiert. Dies lässt sich - wie im vorigen Unterkapitel erläutert - auf die 
von IT-Dienstleistern für ihre Kunden erbrachten Leistungen und das damit ver- 
knüpfte Ertragsmodell zurückführen. So sind die Standardisierungsbemühungen 
der IT-Dienstleister zentral auf die Rationalisierung ihrer Leistungserbringungs- 
prozesse gerichtet. Augenfälligstes Merkmal dieses Bemühens sind die vielfältigen 
Zertifizierungen, die IT-Dienstleister für ihre Geschäftsprozesse durchlaufen, 
und die den Arbeitsprozess in stark formalisierte und standardisierte Teilabläufe 
zerlegen und separat vergleich- und messbar machen sollen. 

Demnach schlägt bei IT-Dienstleistern die Standardisierung und Formalisie- 
rung von Prozessen bis auf die Ebene der Einzelarbeiten durch. Viele Auto- 
ren sprechen daher von einem geradezu „tayloristischen“ Ansatz, der die Tätig- 
keitsprofile der Beschäftigten auf einzelne Teilarbeiten beschränkt, damit frag- 
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mentiert und teilweise auch dequalifiziert (Upadhya und Vasavi 2006, Flecker 
u. a. 2007, Mukherjee 2008). 


Demhingegen kann die bei Produkt-Herstellern vorfindbare Form der Standardi- 
sierung, im Gegensatz zum Bereich der IT-Dienstleister mit Mayer-Ahuja primar 
als Produkt-Standardisierung beschrieben werden (Mayer-Ahuja 2011, S.69). Zen- 
traler Gegenstand von Standardisierung sind im Bereich der Produkt-Herstellung 
(als Folge der Herausbildung modularer Produkt- und Prozessstrukturen) eher die 
Eigenschaften des Produkts als die Eigenschaften von der Erstellung zugrunde lie- 
genden Produktionsprozessen. Wenn Teams an unterschiedlichen Orten separate 
Module einer Applikation entwickeln, so miissen diese einzelnen Komponen- 
ten entsprechend klar spezifiziert und in ihren Schnittstellen genau beschrieben 
sein, damit sich das Produkt anschließend auch integrieren und zusammenfügen 
lässt. Von daher findet zwar eine Aufspaltung des Gesamtprozesses in einzelne 
Module statt und es kommt dadurch auch zu einer gewissen Fragmentierung 
des Arbeitsprozesses. Ob und wie jedoch diese Fragmentierung die Arbeitspro- 
zesse innerhalb jedes einzelnen Moduls betrifft, ist damit noch nicht bestimmt. 
Es kann vielmehr erwartet werden, dass die Form der Standardisierung und 
Formalisierung der Arbeitsprozesse in den jeweiligen Modulen stark davon ab- 
hängig ist, ob die Verlagerung nach dem Muster der „verlängerten Werkbank“ 
erfolgt, oder ob die neuen Standorte mit strategisch wichtigen Aufgaben betraut 
werden und entsprechend komplexere Tätigkeiten zugewiesen bekommen. Die 
Standardisierungsbemühungen bei Produkt-Herstellern im Bereich der Software- 
Entwicklung beziehen sich primär auf die verwendeten Tools der Entwicklung, 
die gemeinsam genutzten Programm-Bibliotheken und das (modulare) Design 
der Software. Einer der augenscheinlichsten Hinweise darauf ist der Umstand, 
dass die externe Zertifizierung, die bei den IT-Dienstleistern mittlerweile ge- 
radezu „zum Geschäft“ gehört, bei den Standardsoftware-Herstellern nur eine 
nebensächliche Rolle spielt. So findet sich unter den seit 2006 mit CMMI Level 5 
bewerteten Unternehmen kein einziger der großen Standardsoftware-Hersteller”. 
Den Hintergrund dieses auf den ersten Blick überraschenden Fehlens erläutert 
die Qualitätsbeauftragte der im Rahmen dieser Studie untersuchten deutschen 
Produktfirma, die eine lange Karriere durch die unterschiedlichsten Firmen der 
indischen IT-Industrie vorzuweisen hat, wie folgt: 


? Die Liste dieser Unternehmen kann auf der Seite des SEI unter http:/ /sas.sei.cmu.edu/pars- 
/pars.aspx eingesehen werden. 
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„Very few product companies in the world ever go for CMMI - it’s mostly 
service companies, who go. Because they work in a project mode - we 
work in a product mode. We per se don’t have a direct end-customer 
for each product. [...] So mostly there is product companies - [...] they 
take best practices, but they don’t necessarily go for a formal certification 
and maintaining the certificate. Whereas you go and talk to any service 
companies, like Accenture may be, or, I don’t know, I-Flex, Infy, Wipro, 
TCS - any company. They will first start with telling that: We are CMM 
Level 5 blablabla. [...] The way that they work is: every project is with the 
customer. And most of these customers expect you to work at a particular 
maturity level in your organization.“ (NB19) 


Dieser Aussage zufolge haben Standardsoftware-Hersteller durch die Abwesen- 
heit von unmittelbaren Kundenbeziehungen einen größeren Spielraum, ihre 
Arbeitsprozesse den eigenen Bedürfnissen nach zu strukturieren. Demnach kön- 
nen Elemente von bekannten Prozessmodellen, wie CMMI oder Six Sigma, zwar 
durchaus auch bei Standardsoftware-Herstellern vorfindbar sein, jedoch besteht 
für Standardsoftware-Hersteller nicht in dem Maße der Zwang, sich für diese Mo- 
delle auch extern zertifizieren zu lassen, wie es bei Dienstleistungsunternehmen 
der Fall ist. 

Freilich bedeutet dies nicht den völligen Verzicht auf Prozessstandardisie- 
rung, die, wie gezeigt, den Bereich der IT-Dienstleistungen dominiert. Auch 
die Hersteller von (Software-)Produkten stehen unter Kosten- und Zeitdruck 
bei der Entwicklung und versuchen dementsprechend auch, den Arbeitsprozess 
organisatorisch zu optimieren. Doch aufgrund der vorwiegend auf das Produkt 
gerichteten Standardisierungsbemühungen und der Abwesenheit direkter Kun- 
denbeziehungen im Produktionsprozess kann für die folgende Untersuchung des 
deutschen Standardsoftware-Herstellers erwartet werden, dass die Standardisie- 
rung und Formalisierung nicht notwendigerweise bis auf die Ebene der einzelnen 
Tätigkeiten durchschlägt. 


Zusammenfassend kann also für die folgenden Fallstudien die Erwartung formu- 
liert werden, dass die Standardisierung und Formalisierung der Arbeitsprozesse 
im Falle von IT-Dienstleistern eine wesentlich wichtigere und weitreichendere 
Funktion besitzt als für die Hersteller von (Software-) Produkten. Es wird sich 
bei der später folgenden Darstellung des deutschen Standardsoftware-Herstellers 
und des indischen IT-Dienstleisters zeigen, wie sich dies auf die betrieblichen 
Kontrollformen von Arbeit auswirkt. 


3 Indien als Offshore-Standort 


Neben den unterschiedlichen Internationalisierungswegen werden in dieser Stu- 
die die Arbeitsmärkte der Zielregionen der räumlichen Verlagerung als wichtiger 
Einflussfaktor auf die Reorganisationsmodi von IT-Unternehmen im Zuge der 
Internationalisierung der IT-Industrie betrachtet. 

Durch Einbeziehung der Arbeitsmärkte der Offshore-Standorte wird somit 
der Ort der Produktion in die Analyse der Art und Weise der Arbeitskontrolle 
integriert. Hintergrund ist die Annahme, dass eine bestimmte Art der Arbeitsor- 
ganisation und -kontrolle immer auch auf die Verfügbarkeit von entsprechend 
qualifizierten Arbeitskräften angewiesen ist. Doch es ist nicht nur die reine Ver- 
fügbarkeit, sondern - gerade im Hinblick auf den indischen Standort - auch die 
Möglichkeit, die Beschäftigten an das Unternehmen zu binden und gemäß den Be- 
dürfnissen des Unternehmens weiterzuentwickeln, die die Formen betrieblicher 
Kontrolle prägt. 

In diesem Kapitel wird anhand der indischen IT-Industrie gezeigt, wie eine 
spezifische Konstellation auf dem Arbeitsmarkt für die [T-Unternehmen zu einer 
organisatorischen Herausforderung wird und somit die Organisation der Ar- 
beitsprozesse in den Offshore-Entwicklungszentren in starkem Maße beeinflusst. 

Zunächst wird in einem kurzen Überblick die boomartige Entwicklung der 
indischen IT-Industrie skizziert, bevor wir uns in einem zweiten Unterkapitel 
der Frage zuwenden, welche Auswirkungen diese Entwicklungen auf den indi- 
schen Arbeitsmarkt hatten und haben und wie das Arbeitskräfteangebot auf dem 
indischen Arbeitsmarkt näher charakterisiert werden kann. 

Das dritte Unterkapitel schließlich beleuchtet den Zusammenhang zwischen 
der Situation auf dem indischen Arbeitsmarkt und den Reorganisationsmodi 
der Unternehmen, wirft also einen ersten Blick auf die Bereiche, in denen sich 
der Arbeitsmarktdruck auf betriebliche Organisations- und Kontrollkonzepte 
auswirkt. 
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3.1 Der Boom der indischen IT-Industrie 


Die indische IT-Industrie ist eine der erfolgreichsten der Welt. Daher hat sie in 
den letzten Jahren auch viel Aufmerksamkeit aus dem wissenschaftlichen Bereich 
auf sich gezogen. Ihre boomartige Entwicklung und die Gründe dafür waren 
Gegenstand zahlreicher Untersuchungen der letzten Jahre!. Wir beschränken 
uns daher an dieser Stelle auf einige wichtige Punkte, die notwendig sind, um 
den Kontext zu verstehen, in dem sich die beiden Untersuchungsfälle im indi- 
schen Bangalore bewegen, und die die Situation auf dem indischen Arbeitsmarkt 
wesentlich beeinflussen. 
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Abbildung 3.1: Umsatzwachstum der indischen IT-Industrie von 1984 - 2009 
(Die Zahlen für diese Grafik sind bis einschließlich 2003 
Athreye (2005b) und ab 2004 NASSCOM (2007, 2009) entnom- 
men. Für die Zeit von 1985-1990 sind leider keine Angaben 
zum Gesamtumsatz vorhanden. Die Angaben für das Jahr 2009 
sind Schätzungen von NASSCOM.) 


! Für zusammenfassende Übersichten, siehe v.a. Dossani 2007, Athreye 2005a und Arora u.a. 
2001. 
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Abbildung 3.1 (S. 48) zeigt das rasante Umsatzwachstum der indischen IT-Indus- 
trie in den letzten Jahrzehnten?. Diese legte in den 1990ern teilweise über 50 
Prozent jährlich zu (vgl. auch Upadhya und Vasavi 2006, S. 8ff.). Zwar nahmen die 
Wachstumsraten auch in Indien ab, doch selbst von 2004 bis 2008 war immerhin 
noch ein jährliches Umsatzwachstum von ca. 33 Prozent zu verzeichnen (vgl. 
auch Deutsche Bank Research 2005, S. 5; Upadhya und Vasavi 2006, S. 8). 

Ein Merkmal, das die indische IT-Industrie von anderen aufstrebenden IT-In- 
dustrien, wie China und Brasilien unterscheidet (vgl. Athreye 2005b), ist die 
starke Exportausrichtung. So wird das Wachstum der IT-Industrie wesentlich 
vom Wachstum der Exporte getragen (vgl. auch Radhakrishnan 2003). Als Ex- 
porte werden sowohl Umsätze erfasst, die von indischen IT-Dienstleistern für 
ausländische Kunden erbracht werden, als auch die Umsätze von Leistungen, die 
von multinationalen Unternehmen in ihren indischen Niederlassungen erbracht 
werden und die auf den Weltmarkt, statt auf den indischen Markt ausgerichtet 
sind. Getragen wird das Wachstum des IT- bzw. IT-Dienstleistungsbereiches zum 
Großteil von den indischen IT-Dienstleistern. Lediglich 20% der Exportumsätze 
wurden 2002 von den Niederlassungen der MNC’s erwirtschaftet (Singh 2005, 
vgl. auch Athreye 2005a). 

Im Gegensatz zum Exportbereich haben der indische IT-Markt und die Um- 
sätze, die auf diesem erzielt werden, nur geringen Anteil am Wachstum der 
Industrie’. 

Allerdings verteilt sich der Umsatz der indischen IT-Industrie in sehr unter- 
schiedlichem Maße auf verschiedene Zielregionen. Wie Abbildung 3.2 (S. 50) 
zeigt, geht der Großteil der Exporte in die USA. Historisch ist die indische IT- 
Industrie vor allem mit Geschäften auf dem amerikanischen IT-Markt gewachsen, 
bevor man sich langsam davon emanzipierte und auch andere Regionen erschlos- 
sen werden konnten. Wie sich aus derselben Abbildung leicht ersehen lässt, ist 
es v.a. der europäische Markt, der zunehmend das Wachstum der indischen IT- 


? Leider ist die Datenlage zur Entwicklung der indischen IT-Industrie sehr mäßig. Die einzigen, 
regelmäßig erhobenen Daten stammen vom indischen Branchenverband NASSCOM. Leider 
ist es relativ unklar, wie belastbar diese Daten sind, da z.B. wenig Informationen darüber 
erhältlich sind, wie genau die Daten erhoben und ausgewertet werden, bzw. wie umfangreich 
die Datengrundlage ist. Nichtsdestotrotz bilden die von NASSCOM bereitgestellten Daten die 
Grundlage fast aller zu diesem Thema veröffentlichten Studien. 

Mit dieser Abhängigkeit vom Export und damit von globalen Kapitalströmen, wird die indische 
IT-Industrie auch in erhöhtem Maße von externen ökonomischen Einflüssen abhängig, ein Punkt 
der als mögliches Risiko für die weitere Entwicklung der Industrie diskutiert wird (Upadhya 
und Vasavi 2006, S. 13). 


w 
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Industrie trägt und im Vergleich zu den USA im Laufe der Jahre immer größere 
Exportanteile auf sich zieht. 
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Abbildung 3.2: Zielregionen der indischen IT-Exporte (Quelle: NASSCOM 
2007, 2009) 


In Bezug auf das Produkt- und Leistungsspektrum kann fiir die indische IT- 
Industrie konstatiert werden, dass der Großteil des Umsatzes durch das Erbringen 
von IT- und BPO-Dienstleistungen* erzielt wird. Abbildung 3.3 (S. 51) zeigt die 
Anteile der unterschiedlichen Branchensegmente am Gesamtumsatz. 


* Unter BPO werden jene Aktivitäten gefasst, die zwar auf einer IT-Infrastruktur basieren, deren 
Kernaktivitäten jedoch nicht IT-spezifisch sind, wie z.B. ausgelagerte Buchführung oder andere 
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Abbildung 3.3: Umsatz der indischen IT-Industrie nach Branchensegmenten 
von 2004 - 2009 (Quelle: NASSCOM 2009) 


Zwar ist ersichtlich, dass sich gerade in den letzten Jahren der Anteil des BPO- 
Bereiches relativ vergrößert, jedoch stellt der IT-Dienstleistungsbereich gegenwär- 
tig noch den dominierenden Bereich der indischen IT-Industrie dar. Höherwerti- 
ge Tätigkeiten, also Forschungs- und Entwicklungsleistungen oder Produktent- 
wicklung sind relativ konstant nur mit einem kleinen Umsatzanteil vertreten, 
wenngleich auch deren Umsatz in absoluten Zahlen wächst”. Allerdings arbei- 
ten Beschäftigte in der Produktentwicklung zum überwiegenden Teil in den 


HR-Funktionen für externe Kunden. Auch Call-Center werden gewöhnlich in diesen Bereich 
gerechnet. 

3 Der Anteil an Produktentwicklung wird in letzter Zeit sehr genau beobachtet und diskutiert, 
weil in einem steigenden Umsatzanteil an höherwertigen Arbeiten wie Forschung & Entwick- 
lung und Produktentwicklung wichtige Upgrading-Tendenzen des indischen Standortes gesehen 
werden. Ob es in letzter Zeit jedoch zu solchen Upgrading-Tendenzen gekommen ist, bzw. wie 
wahrscheinlich solche Tendenzen in Zukunft sind, ist gegenwärtig noch umstritten (vgl. z.B. 
Parthasarathy 2006, Arora 2006, auch Nath und Hazra 2002 
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Niederlassungen westlicher II-Unternehmen, die Komponenten ihrer Software- 
Produkte in Indien entwickeln lassen. Wenngleich indischen IT-Unternehmen 
attestiert wird, auch langsam in die Produktentwicklung vorzustoßen, sind sie in 
diesem Bereich bisher nicht besonders erfolgreich (vgl. Upadhya und Vasavi 2006, 
Radhakrishnan 2003). 


Das Profil der indischen IT-Industrie spiegelt somit die besondere Funktion wider, 
welche diese in der globalen IT-Industrie gegenwärtig einnimmt. So wird Indien 
gegenwärtig zugesprochen, der mit Abstand größte Standort für das Offshoring 
von IT-Arbeit zu sein, wenngleich Statistiken zu diesem Thema sehr selten, 
häufig widersprüchlich und zudem noch politisch aufgeladen sind (vgl. auch 
Stamm 2005, Forrester Research 2004, Upadhya und Vasavi 2006). Im Gegensatz 
zu anderen Offshore-Standorten mit ähnlich hohen Exportanteilen, wie Israel 
oder Irland, liegt der Schwerpunkt der Aktivitäten der indischen IT-Industrie 
jedoch vorwiegend im Bereich der IT-Dienstleistungen und zunehmend auch des 
BPO. Höherwertige Tätigkeiten, wie z.B. die Entwicklung von Standardsoftware, 
findet gegenwärtig in Indien fast ausschließlich in den Niederlassungen der großen 
westlichen IT-Unternehmen statt. 


3.2 Der indische Markt für IT-Arbeitskräfte 


Das im vorigen Unterkapitel skizzierte, rasante Wachstum der indischen IT- 
Industrie hat Konsequenzen für den IT-Arbeitsmarkt in Indien. Galten die vielen 
englischsprachigen, gut ausgebildeten und im weltweiten Vergleich günstigen 
IT-Fachkräfte Indiens stets als besonderes Erfolgsgeheimnis der indischen IT- 
Industrie (u.a. Thomas 2005), so droht gerade ein Fachkräftemangel inzwischen 
für die indische IT-Unternehmen zum Problem zu werden (Arora u.a. 2001). 
Abbildung 3.4 (S. 53) zeigt die dem Umsatzwachstum entsprechend ebenfalls 
rasant verlaufende Zunahme der Beschäftigten in der indischen IT-Industrie. 

Die Entwicklung der Beschäftigtenzahlen unterstreicht noch einmal die oben 
genannte Tatsache, dass das Wachstum der indischen IT-Industrie wesentlich 
vom Exportsektor getragen wird. Auch wenn der Anteil der Beschäftigten, die 
für den indischen Markt arbeiten, über die Jahre steigt, arbeitet doch der über- 
wiegende Teil der IT-Beschaftigten im Export-Sektor. Auffällig ist zudem, dass 
der BPO-Bereich in Bezug auf die Beschäftigtenzahlen sehr großes Gewicht 


° Zum Problem der Messung des Offshoring, siehe auch Deutsche Bank Research 2005. 
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Abbildung 3.4: Entwicklung der Beschäftigtenzahlen der indischen IT- 
Industrie von 2002 - 2009 (Quelle: NASSCOM 2009, Beschäf- 
tigte im Hardware-Bereich nicht mitgezählt) 


besitzt. Dennoch arbeitet der größte Teil der Beschäftigten im IT- (d.h. Produkt- 
entwicklung) und IT-Dienstleistungsbereich. Insgesamt hat sich die Zahl der 
in der indischen IT-Industrie beschäftigten Personen von 2002-2009 mehr als 
vervierfacht. 


Unter dem Druck eines derart rasanten Wachstum kommt es in Indien schon 
seit Mitte der 1990er Jahre zu ersten Anzeichen eines Mangels an IT-Fachkräften, 
der sich im letzten Jahrzehnt stetig erhält, wenn nicht sogar ausweitet (Athreye 
2005a, Upadhya und Vasavi 2006). 

Dabei bezieht sich der Mangel nicht ausschließlich auf die reine Zahl an IT- 
Fachkräften, sondern es wird zudem die Qualifikation der Beschäftigten für die 
Unternehmen zum Problem. Laut einer Studie von NASSCOM und McKinsey 
aus dem Jahre 2005 seien von den indischen Uni-Absolventen lediglich 25% (der 
Absolventen technischer Ingenieurswissenschaften), bzw. 10-15% (aller Fachrich- 
tungen) geeignet, eine Beschäftigung im Exportsektor der indischen IT-Industrie 
aufzunehmen (zitiert nach ebd., S. 26). Dabei sind es nicht nur die fachlichen 
Fertigkeiten, die Anlass zur Sorge geben. Vielmehr fehlen den Absolventen nach 
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Einschätzung vieler Unternehmen „Soft Skills“, wie Sprach- und interkulturelle 
Kenntnisse, um in globalen und multikulturellen Zusammenhängen arbeiten 
und kooperieren zu können (Upadhya und Vasavi 2006, S.25). 

Die Folge ist ein stetig wachsender Konkurrenzkampf der Unternehmen um 
die knappen Arbeitskräfte. Augenfälligste Anzeichen dieser Entwicklung sind 
auf der einen Seite die starken Gehaltssteigerungen für IT-Fachkräfte, und auf 
der anderen Seite die mittlerweile schon legendären Fluktuationsraten innerhalb 
der indischen IT-Industrie. Beide Tendenzen stellen auf unterschiedliche Art 
eine Gefahr für die weitere Entwicklung der indischen IT-Industrie dar und 
stehen daher besonders im Zentrum der öffentlichen und wissenschaftlichen 
Aufmerksamkeit (z.B. ebd., Arora u.a. 2001, auch Mayer-Ahuja und Feuerstein 
2008). 

Steigende Löhne sind eine leicht nachvollziehbare Gefahr für die weitere Ent- 
wicklung der indischen IT-Industrie, da sich durch steigende Personalkosten 
die Kostenvorteile der Verlagerung nach Indien entsprechend reduzieren. Für 
die Boomphase der indischen IT-Industrie während der 1990er Jahre berichtet 
Athreye (2005a) von jährlichen Gehaltssteigerungen von über 30%. Für die Zeit 
nach 2000 kommt der indische Branchenverband NASSCOM in einer gemeinsa- 
men Untersuchung in Zusammenarbeit mit der Unternehmensberatung Hewitt 
zu dem Ergebnis, dass sich die Gehaltssteigerungen zwischen 2002 und 2008 
zwischen 10 und 16,5% pro Jahr bewegten (Nasscom/Hewitt 2008). Zu einer 
ähnlichen Einschätzung gelangt auch Aspray 2006, wobei hier vor allem die 
Abhängigkeit der Steigerungsraten von der Berufserfahrung betont wird. So 
scheinen sich die stärksten Gehaltssteigerungen bei Beschäftigten im mittleren 
und hohen Management zu ereignen (zwischen 15 und 20% jährlich), wohingegen 
bei Berufsanfängern die Gehaltssteigerungen „nur“ zwischen 5 und 10% pro Jahr 
lägen. 

Das ist insofern plausibel, als sich die höchsten Gehaltssteigerungen in der indi- 
schen IT-Industrie durch regelmäßige Firmenwechsel realisieren lassen: Aufgrund 
des großen Bedarfs an Arbeitskräften versuchen die II-Unternehmen sich häufig 
die Beschäftigten gegenseitig abzuwerben, was häufig durch mit dem Angebot 
starker Gehaltssteigerungen und Beförderungen einhergeht (Upadhya und Vasavi 
2006). An dieser Situation haben auch die in den letzten Jahren öffentlich beschlos- 
senen „Anti-Abwerbe-Abkommen“ zwischen einigen IT-Unternehmen nichts 
geändert (Lacity, Rudramuniyaiah und Iyer 2008). So können IT-Beschäftigte 
durch regelmäßige Wechsel ihre Gehälter in kurzer Zeit erheblich steigern. 
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Mit den Gehältern steigen auch die Fluktuationsraten. Während des rasanten 
Wachstums der indischen IT-Industrie während der 1990er Jahre lag diese Quote 
bei gut 25%, d.h. jeder vierte Beschäftigte eines Unternehmens hat im Laufe eines 
Jahres die Firma verlassen. Auch in den 2000ern, als sich das Wachstum etwas 
verlangsamte, lag die Quote noch bei ca. 10-15% (vgl. Arora u.a. 2001; Upadhya 
und Vasavi 2006). 

Doch darf das Phänomen der Fluktuation nicht nur - so wie es Manager der in 
Indien aktiven IT-Unternehmen gerne darstellen - als Ausdruck einer kurzfristig 
dekenden, finanziellen Orientierung der Beschäftigten aufgefasst werden. So 
argumentieren Upadhya und Vasavi (ebd., S. 48ff.), dass die häufigen Unterneh- 
menswechsel der Beschäftigten vor dem Hintergrund der spezifischen Situation 
der indischen IT-Industrie durchaus eine rationale Form der Karriereplanung 
darstellen. So argumentieren sie, dass für die indischen IT-Beschaftigten die wei- 
tere Entwicklung der Branche sehr schwer abzusehen ist. Die Themen, die die 
indischen IT-Dienstleister bearbeiten, und auch die Technologien, mit denen 
sie arbeiten, wechseln stetig mit den Wünschen der Kunden. Und auch bei den 
multinationalen Firmen, die spezielle Produkte in Indien herstellen, ist unklar, 
wie lange diese Unternehmen am indischen Standort bleiben. 

Vor diesem Hintergrund sei es eher eine riskante Strategie, sich zu sehr auf ein 
einzelnes Unternehmen und dessen Themenfeld zu spezialisieren. Daher ist es 
auch langfristig durchaus rational, wenn die indischen Beschäftigten versuchen, 
ihre Berufserfahrung und ihre Qualifikationen möglichst breit zu streuen, um 
für eine möglichst große Zahl an IT-Unternehmen zukünftig attraktiv zu bleiben. 
In diese Richtung argumentiert auch ein Manager von ServiceTec: 


„Deswegen - und sie auch versuchen was, immer was Neues zu werden. 
Wenn die über zwei Jahre nur bei [Kundenname entfernt - PF] arbeiten, 
und die sehen, dass in Industrie, die Leute ... z.B. hier können wir nur ein 
Java-Projekt arbeiten, für zwei Jahre. In zwei Jahre in andere Industrie - die 
Leute haben noch zehn Sachen gelernt. Deswegen die sind auch bisschen 
unglücklich. Das läuft so schnell und so viele neuen Sachen in IT-Bereich 
kommen. Und die möchten mehr lernen und mehr von Projekt zu Projekt 
wechseln, damit nach fünf oder zehn Jahren, die haben so viele Fall-zu-Fall- 
Erfahrung.“ (SD7) 


Für die Unternehmen bedeuten diese hohen Fluktuationsraten, dass das von den 
Beschäftigten aufgebaute Erfahrungswissen und die im Laufe der Zeit erworbe- 
nen Qualifikationen die Firma stetig wieder verlassen. Für die Projekte stellt 
das eine Gefahr dar, da Verzögerungen auftreten, wenn Beschäftigte plötzlich 
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das Team verlassen und durch neue Beschäftigte ersetzt werden müssen, die zu- 
nächst gefunden - angesichts der angespannten Arbeitsmarktlage keine leichte 
Aufgabe - und entsprechend eingearbeitet werden müssen, bis sie voll produktiv 
sind. Gerade in Positionen, wo persönliche Kontakte zu Kunden oder anderen 
Kooperationspartnern relevant sind, stellt dies ein besonderes Problem, dar, da 
sich Vertrauensbeziehungen schlecht entwickeln können, wenn Kontakte ständig 
wechseln. Letztendlich führen die Fluktuationsraten damit auch zu Mehrkosten 
in den Unternehmen, untergraben damit den Kostenvorteil des indischen Stand- 
ortes und damit die zukünftige Entwicklung der indischen IT-Industrie (vgl. auch 
Athreye 2005). 


Es ist daher kein Wunder, dass die Bekämpfung des Arbeitskräftemangels in 
Indien sowohl bei Unternehmen und Branchenverbänden, als auch bei politi- 
schen Entscheidungsträgern unterschiedlicher Ebenen besonders hohe Priorität 
genießt. 

In der Folge finden sich seit Mitte der 90er Jahre diverse Initiativen, sowohl 
die Zahl der für die IT-Industrie geeigneten Uni-Absolventen zu steigern’, als 
auch die Inhalte der universitären Ausbildung an die Bedürfnisse der IT-Industrie 
anzupassen°(für einen guten Überblick über diese Maßnahmen und auch die 
kritische Debatte um diese, siehe v.a. Upadhya und Vasavi 2006). 


3.3 Indischer Arbeitsmarkt und Reorganisationsmodi 


Obwohl von unterschiedlichen Seiten und mit unterschiedlichen Maßnahmen ver- 
sucht wird, das Arbeitskräfteangebot auf dem indischen Arbeitsmarkt quantitativ 
und qualitativ zu verbessern und so die Folgen des Arbeitskräftemangels für die 
Unternehmen zu mildern, besteht dieser gegenwärtig - und voraussichtlich auch 
in näherer Zukunft - fort. Und so stehen die Unternehmen vor der Aufgabe, mit 
dem indischen Arbeitsmarkt umzugehen, sich also organisatorisch auf steigende 
Gehälter und weiterhin hohe Fluktuationsraten einzustellen. 


7 So wurden staatlicherseits im Zeitraum von 1998-99 drei neue - speziell auf die Ausbildung von 
IT-Fachkräften ausgerichtete - Indian Institutes of Information Technology (IIIT) gegründet und 
auch der Bereich der privaten Ausbildungsinstitute (wie z.B. NIIT und Aptech), die Absolventen 
nicht IT-spezifischer Studiengänge eine IT-Industrie geeignete Weiterbildung anbieten, boomt 
seitdem (vgl. Arora u.a. 2001; Athreye 2005a) 

8 Gerade der Branchenverband NASSCOM schaltet sich seitdem zunehmend in die Gestaltung 
der universitären Curricula ein und versucht diese in eine der Industrie dienliche Richtung zu 
verändern. 
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In der Literatur werden verschiedene organisatorische und strategische Maß- 
nahmen diskutiert, mit denen IT-Unternehmen in Indien versuchen, dieser Her- 
ausforderung zu begegnen, und die zeigen, wie weitreichend die Situation auf 
dem Arbeitsmarkt die Form der Arbeitsorganisation am indischen Standort 
beeinflusst. 


Zum stetigen Anstieg der Löhne tragen die IT-Unternehmen dabei selber durch ih- 
re Praxis, erfahrene und gut qualifizierte Beschäftigte von Konkurrenten abzuwer- 
ben, bei. Auch wenn seit Jahren öffentlichkeitswirksam sogen. „Anti-Poaching 
Agreements“ (Abkommen gegen das gegenseitige Abwerben von Beschäftigten) 
zwischen Unternehmen geschlossen werden, geht diese Praxis weiter, und das 
Abwerben von Beschäftigten funktioniert zumeist über das Anbieten von Ge- 
haltssteigerungen beim Firmenwechsel. Die von Managern in Indien häufig zu 
hörende Klage, Beschäftigte würden schon „for a few Rupees“ die Firma wechseln, 
ist daher zu einem nicht unerheblichen Teil auch ein selbst gemachtes Problem 
der Industrie. 

Demnach laufen die Maßnahmen, die von IT-Unternehmen gegen die rasanten 
Lohnsteigerungen ergriffen werden, vorwiegend darauf hinaus, die Produktivität 
der Beschäftigten zu steigern und somit die steigenden Lohnkosten auszugleichen. 

Ein Mittel dazu kann sein, für bestimmte Aufgaben, die keine tiefe TT-spezi- 
fische Ausbildung erfordern, zunehmend auf weniger qualifizierte Beschäftigte 
zurückzugreifen, die entsprechend weniger umkämpft sind und daher weniger 
hohe Gehaltsforderungen stellen können (Athreye 2005a). Dies bedeutet, dass 
IT-Unternehmen bei der Rekrutierung zunehmend auch Beschäftigte mit nicht 
IT-spezifischer Ausbildung berücksichtigen. Schon lange sind in Indien alle Arten 
von „Engineering“-Absolventen die primäre Zielgruppe bei der Rekrutierung 
durch IT-Unternehmen (vgl. Upadhya und Vasavi 2006; Ilavarasan 2007; Athreye 
2005a; Abraham und Sharma 2005)’. Da diese aber entsprechend stark umkämpft 
sind, versuchen einige Unternehmen, mithilfe einer Art „Babbage-Prinzip“!° 


> 


? Genau genommen handelt es sich schon beim Großteil der Engineers auf dem indischen Ar- 
beitsmarkt um IT-ferne Arbeitskräfte. Denn Studierende des civil- oder mechanical-engineering 
(Bauingenieurwesen bzw. Maschinenbau) studieren auch kein IT-spezifisches Fach. Dass den- 
noch generell Absolventen aller Engineering-Studiengängen in Indien zur Kerngruppe der 
IT-Fachkräfte gezählt werden, liegt daran, dass angenommen wird, dass Studierende dieser 
Fachrichtungen wichtige Sekundärqualifikationen mitbringen (z.B. technisches Verständnis, 
logisches Denken), die sie für eine Beschäftigung in der IT-Industrie grundsätzlich geeignet 
machen. 

„Das Babbage-Prinzip (nach Charles Babbage) besagt, dass die Aufspaltung eines Arbeitsprozes- 
ses in unterschiedlich anspruchsvolle Teilprozesse die Lohnkosten für die Produktion senkt. 
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Tätigkeiten, die keine tiefere IT-spezifische Ausbildung erfordern, zunehmend 
durch Absolventen anderer Studienfächer erledigen zu lassen (Athreye 2005b). 
Die Absolventen werden zu diesem Zweck mithilfe betriebsinterner Trainings- 
maßnahmen entsprechend geschult (vgl. auch Arora u. a. 2001). Gerade die großen 
indischen IT-Dienstleister haben in den letzten Jahrzehnten beachtliche betrieb- 
liche Trainingseinrichtungen geschaffen, in denen neu rekrutierte Beschäftigte 
gemäß der betrieblichen Bedürfnisse aus- und weitergebildet werden. 

Von steigender Bedeutung ist in dieser Hinsicht aber auch der private Trai- 
ningsbereich, also jene Unternehmen und Bildungsinstitutionen, die Weiterbil- 
dungsmöglichkeiten für Absolventen anderer Studienfächer anbieten und diesen 
einen IT-fahigen Abschluss, in Form von speziellen Diplomen, verleihen. Grund- 
sätzlich werden diese Arbeitskräfte vom Qualifikationsniveau her nicht so hoch 
geschätzt wie die Engineering-Absolventen, doch für bestimmte Aufgaben lassen 
sich auch diese Beschäftigten im Unternehmen einsetzen. Dies schafft die Voraus- 
setzung dafür, die höher qualifizierten Beschäftigten ausschließlich jene Aufgaben 
bearbeiten zu lassen, für die ihre Qualifikation unbedingt nötig ist (Arora u. a. 
2001; Athreye 2005a). So ziehen die neuen Rekrutierungsstrategien gleichzeitig 
neue Formen der Arbeitsteilung und Spezialisierung im Arbeitsprozess nach 
sich. 

Ein anderes Mittel, die Kostensteigerungen durch steigende Löhne auszuglei- 
chen, ist die Steigerung der Produktivität der Arbeitsprozesse selbst. So führt 
z.B. Prasad 1998 das seit 1993 in der indischen IT-Industrie grassierende „ISO- 
Fever“!! wesentlich auf den Arbeitskräftemangel der indischen IT-Industrie in 
den Boomjahren der 1990er zurück. Diese Prozessmodelle - so war die Erwartung 
- sollten die Effizienz der Arbeitsprozesse steigern und somit den Personalbedarf 
reduzieren (ebd., S. 446). In die gleiche Richtung geht auch die zunehmende 
Nutzung von Software-Tools (Athreye 2005a, S. 34). Diese können einerseits 
helfen, Arbeitsprozesse durch computergestützte Prozeduren zu effektivieren, an- 
dererseits bieten sie ein Automatisierungspotential (wie z.B. bei automatisierten 


Babbage formulierte dieses Prinzip erstmals in seinem 1832 in London erschienenen Werk 
On the Economy of Machinery and Manufactures. [...] Voraussetzung ist die unterschiedliche 
Entlohnung unterschiedlich anspruchsvoller Arbeit (bzgl. Qualifikation, Anstrengung etc.)“ 
(Wikipedia 2010a). 

11 Gemeint ist die Zunahme der Aufmerksamkeit, die der Qualitätssicherung bei Softwareentwick- 
lung in Form von standardisierten Prozessmodellen und Evaluationen geschenkt wird. Dies 
beinhaltete zunächst vor allem eine Zertifizierung nach dem ISO-Standard 9001, später gesellten 
sich weitere Zertifizierungen wie CMMI oder auch Six Sigma dazu. 
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Testverfahren), welches den Bedarf an Arbeitskraft in der Produktion zusätzlich 
reduziert. 


Doch die Einführung der standardisierten Prozessmodelle bietet nicht nur die 
Möglichkeit, den Personalbedarf zu reduzieren und so Lohnkosten zu sparen, sie 
bilden auch den zentralen Mechanismus, mit dem einige Unternehmen in Indien 
versuchen, mit den Folgen der hohen Personalfluktuation umzugehen. Dabei 
kann zwischen zwei grundsätzlichen Strategierichtungen unterschieden werden, 
die sich keineswegs immer gegenseitig ausschließen, sondern vielmehr teilweise 
gut ergänzen können (vgl. auch Mayer-Ahuja und Feuerstein 2008). 

Die Einführung standardisierter Prozessmodelle bildet dabei den zentralen 
Kern der einen Strategie, die darauf abzielt, die Arbeitsprozesse gegen hohe Fluk- 
tuationsraten möglichst weitgehend zu immunisieren, indem die Arbeitsprozesse 
möglichst unabhängig von den beteiligten Personen gemacht werden sollen. Denn 
mit den Prozessmodellen einher gehen Bemühungen, das Ausmaß der Dokumen- 
tation der Arbeitsschritte zu erhöhen und den Arbeitsprozess zunehmend eng 
und detailliert zu überwachen. Die negativen Folgen einer Kündigung für die 
Unternehmen (in Form des Verlusts von individuellem und Erfahrungswissen der 
Beschäftigten) sollen so möglichst gering gehalten werden (Athreye 2005b, Arora 
u.a. 2001, Prasad 1998). Hier wird der Arbeitskräftemangel also zu einem eigen- 
ständigen Motiv für die Industrialisierungsbemühungen der IT-Unternehmen in 
Indien: in der Absicht, das Unternehmen und die laufenden Projekte gegen die 
hohen Fluktuationsraten zu immunisieren, treiben Unternehmen die Standardi- 
sierung und Formalisierung ihrer Arbeitsprozesse voran. 

Doch selbst wenn die Abhängigkeit von einzelnen Beschäftigten durch for- 
malisierte und standardisierte Prozessmodelle reduziert werden kann - gänzlich 
abgeschafft werden kann sie nicht (vgl. zu einer ähnlichen Einschätzung Arora 
u. a. 2001). Gerade in höheren Managementpositionen und bestimmten techni- 
schen Spezialisierungsrichtungen bestehen Abhängigkeiten in hohem Maße fort 
und Unternehmen sind weiter von Fluktuation bedroht. Demnach findet sich 
neben dem Versuch, die Arbeitsprozesse gegen Fluktuation zu immunisieren, 
auch eine Strategie, die darauf abzielt, Fluktuation zu reduzieren. 

Diese Strategie besteht in der Gewährung besonderer Anreize - nicht nur 
finanzieller Natur - für die Beschäftigten, in der Firma zu bleiben. 

Dazu zählen zunächst finanzielle Anreize, wie z.B. stark ansteigende Gehälter 
in Abhängigkeit von Betriebszugehörigkeit, Sonderzulagen oder Aktienanteile 
am Unternehmen (ebd.). 
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Darüber hinaus ist allerdings auch die Eröffnung attraktiver Karrierewege im 
Unternehmen ein wesentlicher Anreiz für die Beschäftigten, im Unternehmen 
zu bleiben (Athreye 2005a, Arora u.a. 2001). Der Nachteil ist, dass schnelle 
Beförderungen und steile Karrieren in der Folge von den Beschäftigten geradezu 
„erwartet“ werden und sie bei Ausbleiben einer Beförderung die Firma auch 
verlassen. Dadurch werden die Firmen förmlich gezwungen, regelmäßig und 
in teilweise sehr kurzen Zeitabständen zu befördern (vgl. ebd., Upadhya und 
Vasavı 2006, Abraham und Sharma 2005). In den multinationalen Unternehmen, 
gerade auch im deutschen Unternehmen des Untersuchungssamples dieser Studie, 
stößt diese Form der Beförderungen auf gänzlich andere Praktiken aus den 
Heimregionen der Unternehmen und wird von diesen Unternehmen daher nur 
langsam adaptiert (vgl. auch Arora u. a. 2001). 

Der letzte Anreiz, der an dieser Stelle hervorgehoben werden soll, besteht 
letztendlich auch im Angebot interessanter Arbeit. Lacity, Rudramuniyaiah und 
Iyer (2008) zeigen in ihrer Studie zu den Fluktuationsraten in der indischen 
IT-Industrie, dass die Suche nach einer befriedigenden Tätigkeit ein ganz wesent- 
licher Faktor bei der Entscheidung der Beschäftigten ist, ein Unternehmen zu 
verlassen oder in einem zu verweilen. Dies betrifft zum einen natürlich die Art 
der Tätigkeiten, welche die Beschäftigten in Indien ausführen sollen. Gerade im 
Zusammenhang mit verlagerten Tätigkeiten und Kooperationen in transnatio- 
nalen Projektteams bildet zum anderen aber auch die Möglichkeit, am Standort 
des Kunden oder des Mutterhauses arbeiten zu können, eine arbeitsinhaltliche 
Herausforderung und damit einen guten Anreiz für die Beschäftigten, länger im 
Unternehmen zu bleiben (vgl. auch Arora u. a. 2001). 

Es wurde oben argumentiert, dass sich die beiden Strategierichtungen des 
Umgangs mit Fluktuation - Immunisierung und Reduzierung - nicht notwen- 
digerweise widersprechen, sondern sich teilweise auch ergänzen können. So 
kann ein stark standardisierter Arbeitsprozess, der die Abhängigkeit von den 
einzelnen Beschäftigten stark reduziert, durchaus mit einem finanziellen An- 
reizsystem koexistieren, das ein längeres Verweilen der Beschäftigten im Betrieb 
durch in Abhängigkeit von der Betriebszugehörigkeit stark steigende Gehälter 
fördern soll. Gerade an der Gewährung interessanter Arbeit zeigen sich jedoch 
auch die Grenzen der Vereinbarkeit beider Strategierichtungen. So resultiert die 
Standardisierung und Formalisierung der Arbeitsprozesse im Zuge der Immuni- 
sierung gegen Fluktuation ja gerade darin, die Arbeitsaufgaben zu verkleinern 
und interpersonell austausch- und wiederholbar zu machen, was häufig mit der 
Reduzierung der Attraktivität der Arbeitsaufgaben einhergeht. An dieser Stel- 
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le besteht also ein Widerspruch zwischen den beiden Strategierichtungen, und 
Unternehmen können unterschiedliche Entscheidungen treffen. 


Die verschiedenen Ansatzpunkte, mit den hohen Gehaltssteigerungen und Fluk- 
tuationsraten am indischen Standort organisatorisch umzugehen, begründen 
somit ein weites Spektrum möglicher betrieblicher Strategien. Dementsprechend 
kann aus der Situation auf dem Arbeitsmarkt auch keine gleichförmige Wirkung 
auf die Formen der betrieblichen Arbeitsorganisation und -kontrolle abgeleitet 
werden. Vielmehr muss berücksichtigt werden, dass Unternehmen in unterschied- 
licher Weise versuchen können, mit den strukturellen Herausforderungen des 
indischen Arbeitsmarktes organisatorisch umzugehen. 

Wie sich bei den im Rahmen dieser Studie untersuchten IT-Unternehmen 
noch genauer zeigen wird, sind es die unterschiedlichen Geschäfts- und Verlage- 
rungsmodelle der Unternehmen, die einen wesentlichen Einfluss darauf haben, 
wie stark die Unternehmen von den Eigenheiten des indischen Arbeitsmarktes 
betroffen sind, und wie sie sich in Bezug auf diese Herausforderungen verhalten 
und welcher Strategie des Umgangs sie dabei folgen. Es wird sich zeigen lassen, 
dass sich in Abhängigkeit von den zugrundeliegenden Verlagerungsmodellen 
ganz unterschiedliche Formen herausbilden, mit dem indischen Arbeitsmarkt 
umzugehen, und dass der indische Arbeitsmarkt, auf dem beide Unternehmen 
gleichermaßen operieren, damit unterschiedliche organisatorische Umgangsfor- 
men zulässt. 


4 Reorganisationsmodi: 
Varianten betrieblicher 
Arbeitsprozesskontrolle 


Die zentrale Hypothese dieser Studie besagt, dass sich in der IT-Industrie im 
Zuge ihrer Internationalisierung weniger eindeutige und gleichförmige Industria- 
lisierungstendenzen als vielmehr unterschiedliche Reorganisationsmodi identi- 
fizieren lassen, die auf der einen Seite von unterschiedlichen Internationalisie- 
rungswege und auf der anderen Seite von den Arbeitsmarktbedingungen der 
Offshore-Standorte geprägt sind. Untersucht werden sollen die unterschiedlichen 
Reorganisationsmodi in ihrem Einfluss auf die in ihnen jeweils enthaltene Form 
der Kontrolle von Arbeit. 

In den vorausgehenden Kapiteln wurden die beiden in dieser Studie berück- 
sichtigten Internationalisierungswege (Offshore-Outsourcing und Captive-Off- 
shoring), sowie die besonderen Arbeitsmarktbedingungen des indischen IT-Stand- 
ortes, näher erläutert. Das folgende Kapitel wird nun bestimmen, mit welchem 
Analysekonzept und in welchen Dimensionen die Unterschiede der betrieblichen 
Kontrolle zwischen den beiden Untersuchungsfällen untersucht werden sollen. 


Als Anforderung an das gesuchte Analysekonzept lassen sich zwei zentrale Aspek- 
te formulieren: 


- Das Analysekonzept muss erstens in der Lage sein, die Veränderungen in 
der Form der betrieblichen Kontrolle im Zuge der Industrialisierung von 
IT-Arbeit angemessen fassen zu können. 


- Darüber hinaus muss es das Analysekonzept zweitens ermöglichen, die 
erwarteten unterschiedlichen Reorganisationsmodi als unterschiedliche 
Ausprägungen und Mischungsverhältnisse derselben Dimensionen von 
Arbeitskontrolle zu fassen und zu interpretieren. 


Wie in den folgenden Unterkapiteln argumentiert werden soll, bietet ein von 
Andrew Friedman (1977) in der „Labour Process Debate“ vorgeschlagenes Kon- 
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zept zur Untersuchung betrieblicher Formen von Arbeitskontrolle genau diese 
Möglichkeiten und wird daher den folgenden Ausführungen zugrunde gelegt. 


4.1 IT-Industrialisierung: ein grundlegender 
Strategiewechsel 


Wie bereits in der Einleitung angedeutet, kann die von den Vertretern der In- 
dustrialisierungsthese erwartete Industrialisierung von IT-Arbeit im Zuge ihrer 
zunehmenden Internationalisierung als ein wesentlicher Umbruch in der Form der 
Kontrolle von IT-Arbeit gefasst werden. 

Einen gewinnbringenden Zugang zu dem damit angerissenen Problemkomplex 
betrieblicher Formen der Kontrolle von Arbeit bietet nach wie vor das von 
Braverman (1980) unter Bezug auf Marx als Auftakt der „Labour Process Debate“ 
herausgearbeitete Transformationsproblem!. 

Mit dem Transformationsproblem wird ein Grundproblem des kapitalistischen 
Arbeitsprozesses angesprochen: Wenn Unternehmen Arbeitskräfte rekrutieren 
und einstellen, ist keineswegs sichergestellt, dass deren Gebrauchswert - die von 
den Beschäftigten zu leistende lebendige Arbeit - durch das Unternehmen in 
der gewünschten Intensität und Qualität auch genutzt werden kann. Das Un- 
ternehmen kauft Arbeitskraft, die Arbeit ist zu diesem Zeitpunkt noch reine 
Potentialität, das Unternehmen muss die Beschäftigten wirklich arbeiten las- 
sen, um den Gebrauchswert der Ware Arbeitskraft zu nutzen. Dabei obliegt 
die Form der Nutzung der gekauften Ware dem Unternehmen, d.h. es wird 
versuchen, den Gebrauchswert, den es aus der gekauften Ware ziehen kann, zu 
maximieren. Konkret heißt das, die Arbeit der Beschäftigten in quantitativer (Ar- 
beitszeit) und qualitativer Hinsicht (Arbeitsintensität), so weit wie möglich über 
den Punkt hinaus zu verlängern, an dem der Arbeitende das Äquivalent seiner 
eigenen Reproduktionskosten geschaffen hat. Dies tut das Unternehmen, indem 
es die Umstände der Produktion, die seiner Verfügung unterliegen, v.a. technisch- 
organisatorisch zu beeinflussen versucht (vgl. u.a. Braverman 1980; Deutschmann 
2002; Thompson 1989; Voß und Pongratz 1998). Dem Management erwächst aus 
diesem Grundsachverhalt kapitalistischer Arbeit ein genereller Kontrollimperativ 


1 Die „Labour Process Debate“ entfaltete anfänglich vor allem im angelsächsischen Raum Wirkung. 
Mittlerweile haben aber die zentralen Einsichten dieser Debatte auch Eingang in weitere Bereiche 
und auch in die deutsche Debatte gefunden, so dass das Transformationsproblem mittlerweile 
quasi arbeitssoziologisches Lehrbuchwissen darstellt (vgl. auch Deutschmann 2002). 
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(vgl. Thompson 1989), d.h. auf die eine oder andere Weise muss das Management 
die Transformation von Arbeitskraft in lebendige Arbeit bewerkstelligen. 

Entgegen der Annahme Bravermans wird heute davon ausgegangen, dass die 
Form, in der dieser Kontrollimperativ vom jeweiligen Management konkret 
umgesetzt wird, keinesfalls determiniert ist?, sondern dass sich in verschiedenen 
Branchen - mit verschiedenen Arten von Arbeit - und sogar innerhalb ein 
und desselben Unternehmens unterschiedliche Formen der Arbeitskontrolle 
identifizieren lassen. 


Die IT-Industrie mit ihren kreativen und wissensbasierten Tätigkeiten, stand 
dabei in den letzten Jahren im Zentrum der Debatte über „neue Formen“ von 
Arbeit, die (je nach Autor) im Übergang der Industriegesellschaft zur Wissens- 
oder Informationsgesellschaft an Bedeutung gewinnen. Kennzeichen dieser neuen 
Art von Arbeit sei die Abkehr von Formen technisch-bürokratischer Kontrolle 
des Arbeitsprozesses, die als überkommene Formen des tayloristisch-fordistisch- 
en Industriezeitalters angesehen wurden. IT-Arbeit hingegen - so wurde generell 
konstatiert - bedürfe spezieller, wesentlich anderer Kontrollformen (u.a. Töpsch, 
Menez und Malanowski 2001; Heidenreich und Töpsch 1998; Voß und Pongratz 
1998; Willke 1998). 

Aufgrund der „Stofflichkeit“ der Arbeit, ihres kreativen und innovativen Cha- 
rakters, sei es für Manager von IT.Arbeit wesentlich schwerer, klar definierte 
Arbeitspakete zu schneiden, die in der Folge dann eng überwacht abgearbeitet 
werden könnten. Vielmehr zeichneten sich Aufgaben in der IT-Industrie durch 
eine hohe Komplexität und damit einhergehend hohe qualifikatorische Anforde- 
rungen aus. Probleme und Schwierigkeiten der Aufgabenbewältigung zeichneten 
sich meist erst im Verlauf ab, Lösungen könnten daher schwerlich im voraus 
verbindlich bereitgestellt werden. Daher - so wurde argumentiert - seien die 
Beschäftigten gefordert, auf solche Probleme möglichst eigenverantwortlich und 
schnell zu reagieren und selbständig eine entsprechende Lösung zu finden (vgl. 
Voß und Pongratz 1998). 

Solch gewünschtes Verhalten muss organisatorisch unterstützt werden, da an- 
genommen wurde, dass eine „herkömmliche, auf Funktionsspezialisierung und 
Aufgabenteilung, Kompetenzabgrenzung und Einzelentscheidung beruhende 


? Braverman ging zu Beginn der Labour Process Debate noch von einem quasi naturwiichsigen 
Zusammenhang zwischen kapitalistischem Arbeitsprozess und tayloristischer Form der Arbeits- 
kontrolle aus. Im Laufe der Debatte wurde gerade dieser Zusammenhang zunehmend kritisiert 
und durch eine differenziertere Konzeption ersetzt (für einen guten Überblick, siehe Thompson 
1989). 
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hierarchische Organisationsform [...] für komplexe Aufgabenstellungen und Ent- 
scheidungsmaterien immer weniger geeignet“ sei (Kalkowski und Mickler 2009, 
S.9). Als dominante Organisationsform habe sich daher bei IT-Firmen? die Form 
von Projektteams durchgesetzt, böten diese doch „grundsätzlich flache Hierarchi- 
en und ein[en] locker[en] Umgangston auch mit Vorgesetzten, Ganzheitlichkeit, 
kollegiale Zusammenarbeit jenseits bürokratischer Vorschriften, Autonomie so- 
wie Lern- und Entwicklungsmöglichkeiten“ (ebd., $.11). Die organisatorische 
Form des Projektes unterstütze damit teamförmiges Arbeiten und gewähre den 
Beschäftigten hohe Selbstorganisationsmöglichkeiten, um komplexe Probleme 
zu bearbeiten. 

Kurzum, die Kontrolle von IT-Arbeit wurde in der arbeitssoziologischen 
Forschung geradezu als Prototyp für Formen „indirekter“ Kontrolle angesehen. 
Daran änderten auch vereinzelte Studien nichts, die das Fortbestehen von direkter 
Kontrolle auch bei IT-Arbeit demonstrierten (vgl. z.B. Kraft und Dubnoff 1986; 
Kraft 1979; Barrett 2005; Prasad 1998; Friedman 1990a; Friedman 1992; Mayer- 
Ahuja und Wolf 2005). 


Mit dem Einsetzen der räumlichen Verlagerung von IT-Arbeit scheint sich nun 
die Realität in der IT-Industrie stark zu verändern. Das zugrundeliegende Trans- 
formationsproblem wird im Zuge der Internationalisierung, so die Erwartung 
vieler Autoren, im Sinne einer Industrialisierung von IT-Arbeit zu lösen versucht 
- es finde also ein grundsätzlich anderer technisch-organisatorischer Zugriff auf 
die Arbeitsleistung der Beschäftigten statt. 

So wird erwartet, dass die vormals ganzheitlichen Aufgabenprofile der Ent- 
wickler zugunsten stärker (global) arbeitsteiliger Profile ersetzt würden. Die 
Folge seien Tätigkeitsprofile für Entwickler, deren Arbeitsaufgaben einerseits 
kürzer terminiert und andererseits auch weniger komplex sind, da sie engere 
und inhaltlich stärker auf Teilfunktionen spezialisiert seien. Mit dieser Fragmen- 
tierung der Tätigkeitsprofile und der Arbeitsaufgaben gehe dann in der Folge 
auch eine stärkere Durchdringung der Arbeitsprozesse mithilfe von zentralen 
Informationssystemen einher, die eine detailliertere Messung der Arbeitsleistung 
der Beschäftigten und ein engeres Monitoring der Arbeitsabläufe ermögliche 
(Kampf 2008, S.27ff.). Dadurch würden die Beschäftigten einer detaillierteren 
und stärker formalisierten Form der Kontrolle unterworfen. Die aus anderen 
Branchen bekannte bürokratische Beherrschung des Arbeitsprozesses in Form 


> Natürlich betrifft dieser Trend nicht nur die IT-Industrie, doch wurde die IT-Industrie stets als 
Trendsetter dieser Entwicklung angesehen, an deren Erfahrungen sich auch andere Branchen 
orientieren würden. 
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von standardisierten Prozessmodellen mit genau definierten Schritten der Be- 
arbeitung halte demnach auch zunehmend bei IT-Arbeit Einzug. Schlief lich 
werde damit auch die traditionelle Beschaftigungssicherheit von IT-Beschäftigten 
untergraben, indem die Arbeitsprozesse durch die fortschreitende Standardisie- 
rung und Formalisierung von den einzelnen Beschäftigten unabhängiger und die 
Beschäftigten damit auch leichter ersetzbar würden. Damit verändere sich die 
Verhandlungsgrundlage zwischen Beschäftigten und Management, weil die neue 
Ersetzbarkeit vom Management genutzt werden kann, um Zugeständnisse bei 
den Beschäftigungsverhältnissen durchzusetzen. 


Der von den Vertretern der Industrialisierungsthese behauptete Wandel im or- 
ganisatorisch-technischen Zugriff auf die Arbeitsleistung der Beschäftigten (vgl. 
Voß und Pongratz 1998, $.137) verläuft damit genau entlang jener Achse, deren 
Pole Friedman (1977) in seiner - inzwischen als klassisch zu bezeichnenden 
- Konzeption als die beiden Strategietypen der „direkten Kontrolle“ und der 
„verantwortlichen Autonomie“ bezeichnet hat. 


4.2 Managementstrategien zwischen „verantwortlicher 
Autonomie“ und „direkter Kontrolle“ 


Die Unterscheidung zwischen den beiden Strategierichtungen geht auf die spezi- 
ellen Eigenschaften der Ware Arbeitskraft zurück. Nach Friedman unterscheidet 
sich die Ware Arbeitskraft von den anderen vom Management eingekauften 
Produktionsfaktoren vor allem durch zwei wesentliche Eigenschaften: 


„Zum einen sind die Arbeiter besonders anpassungsfähig: Wenn sie erstmal 
eingestellt sind, dann können sie zu Tätigkeiten veranlasst werden, die über 
das hinausgehen, was ursprünglich im Arbeitsvertrag festgelegt worden ist. 
Zum anderen wird ihr Verhalten letztlich von einem unabhängigen und 
oftmals eigensinnigen Willen bestimmt.“ (Friedman 1987, S. 100) 


Die Beziehung zwischen Kapital und Arbeit ist in dieser Fassung also eine höchst 
widersprüchliche: 


„Es besteht immer eine grundsätzliche Spannung zwischen der Notwendig- 
keit, Kooperation oder Zustimmung von denen, die die Arbeit machen, zu 
erlangen und der Notwendigkeit, sie zu Dingen zu zwingen, die sie nicht 
tun wollen und sie auf eine Art und Weise zu behandeln, die gegen ihre eige- 
nen Interessen verstößt, damit die Ziele von denen, die den Arbeitsprozess 
beherrschen, erreicht werden.“ (ebd., S. 108) 
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Das Ziel des Managements, möglichst effizient das Arbeitsvermögen in Arbeit 
zu transformieren, kann nach Friedman daher im Extremfall auf zwei Wegen 
erreicht werden. 

Entweder die Anpassungsfahigkeit der Arbeitenden wird genutzt, indem ver- 
sucht wird, deren Loyalitat und freiwillige Leistungsbereitschaft durch Uber- 
tragung von Verantwortung und Selbststeuerungsméglichkeiten zu gewinnen. 
Diese Strategierichtung beinhaltet die Gewahrung von verantwortlicher Autono- 
mie. Ergebnis ist 


„the maintenance of managerial authority by getting workers to identify 
with the competitive aims of the enterprise so that they will act responsibly 
with a minimum of supervision“ (Friedman 1977, S. 48). 


Unschwer lassen sich die Parallelen zwischen Kontrollstrategien nach dem Muster 
der „verantwortlichen Autonomie“ und dem erkennen, was traditionell über die 
Form der Kontrolle von IT-Arbeit vertreten wird (vgl. u.a. Boes 2004; Kämpf 
2008). 

Die zentralen Veränderungen in der Form der Kontrolle, die von den Ver- 
tretern der Industrialisierungsthese im Zuge der Internationalisierung der IT- 
Industrie für die Arbeitsprozesse erwartet werden, bewegen sich hingegen eher 
in eine Richtung, die Friedman Strategien der „direkten Kontrolle“ nennt. 

Strategietypen der direkten Kontrolle finden sich beispielhaft in den tayloristi- 
schen Formen der Arbeitszerlegung und -kontrolle. Diese Strategie richtet sich 
eher gegen die Eigensinnigkeit der Arbeitenden und versucht, 


„das Maß der Verantwortlichkeit jedes Einzelnen durch strenge Überwa- 
chung zu reduzieren. Man bestimmt im voraus und bis ins kleinste Detail 
die spezifischen Aufgaben, die einzelne Arbeiter zu erledigen haben“ (Fried- 
man 1987, S. 100). 


Das entscheidende Merkmal, das die beiden Strategierichtungen der „direkten 
Kontrolle“ und der „verantwortlichen Autonomie“ unterscheidet, ist also der 
Handlungs- und Verantwortungsspielraum, der den einzelnen Beschäftigten bei 
der Verrichtung ihrer Arbeitsaufgaben eingeräumt wird. Wird bei Strategien 
direkter Kontrolle versucht, den individuellen Handlungsspielraum möglichst 
gering zu halten, wird das individuelle Handeln im Arbeitsprozess dabei geradezu 
als Risiko und unerwünschte Quelle potentieller Störungen betrachtet, so wird 
bei Strategien der Gewährung von verantwortlicher Autonomie versucht, das 
explizit erwünschte eigenverantwortliche Handeln in den Dienst des Unterneh- 
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mens zu stellen, indem mithilfe unterschiedlichster Maßnahmen an die Loyalität 
des Einzelnen appelliert wird. 

Aufgrund der Bedeutung individueller Handlungsspielräume sollen in dieser 
Studie Strategien, die dem Muster der direkten Kontrolle folgen, auch restriktive 
Kontrollstrategien genannt werden, weil sie individuelle Handlungs- und Ent- 
scheidungsspielräume einschränken. Kontrollstrategien, die eher dem Muster der 
Gewährung von verantwortlicher Autonomie folgen, sollen dagegen als permissi- 
ve Kontrollstrategien bezeichnet werden, weil sie diese Spielräume erhalten, bzw. 
danach trachten, sie zu erweitern. 


Für die vorliegende Studie ist diese begriffliche Differenzierung vor allem deshalb 
von besonderer Bedeutung, weil Friedman sie eher als zwei Pole eines Kontinu- 
ums, denn als unverbundene Alternativen zueinander versteht (vgl. Friedman 
1990b). So wird eine betriebliche Kontrollstrategie immer Mischungsverhältnis- 
se restriktiv und permissiv wirkender Elemente enthalten und die strategische 
Orientierung kann in unterschiedlichen Bereichen, Abteilungen und Beschäftig- 
tengruppen des Unternehmens durchaus variieren (vgl. Deutschmann 2002, S. 
118). So verstanden, bilden die beiden Strategietypen eher zwei Richtungen, 


„in die sich Manager bewegen können und nicht [...] zwei vordefinierte 
Strategien, zwischen denen Manager wählen“ (Friedman 1987, S.101). 


Diese Einschränkung ist insofern wichtig, als sie es nicht nur gestattet, den 
Ausgangs- und Fluchtpunkt der Veränderungen in Formen der Kontrolle von 
IT-Arbeit im Zuge ihrer Industrialisierung zu bestimmen, sondern auch un- 
terschiedliche Reorganisationsmodi, wie sie in dieser Studie im Zentrum der 
Aufmerksamkeit stehen sollen, als unterschiedliche Positionen innerhalb die- 
ses - mit den beiden Strategierichtungen als Pole begrenzten - Kontinuums 
zu interpretieren. Ein Wandel der Kontrollformen erscheint so als eine Bewe- 
gung zwischen diesen Polen, und die unterschiedlichen Reorganisationsmodi 
der IT-Industrie können als eine je spezifische Zunahme restriktiver Formen der 
Kontrolle interpretiert werden. 
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4.3 Betriebliche Kontrolle: zur strategischen Gestaltung 
von Aktivitatsfeldern 


Um die unterschiedlichen Reorganisationsmodi in der IT-Industrie und deren 
Folgen für die Formen der Kontrolle miteinander vergleichen und interpretieren 
zu können, müssen diese als Kombination unterschiedlicher Ausprägungen von 
bestimmten Dimensionen von Kontrolle fassbar sein. 

Auch hierbei stellt der Ansatz Friedmans einen nützlichen Untersuchungsrah- 
men bereit. Der Grundgedanke der Friedmanschen Konzeption zur Bestimmung 
der in einem Unternehmen verfolgten Kontrollstrategie besteht darin, dass die 
grundsätzliche Unterscheidung zwischen den Kontrollstrategien „verantwort- 
liche Autonomie“ und „direkte Kontrolle“ sich an bestimmten strategischen 
Aktivitäten des Managements in unterschiedlichen Dimensionen der Arbeits- 
organisation - sogen. Aktivitätsfeldern - festmachen lasse. Vier zentrale Akti- 
vitätsfelder stellen demnach die zentralen Dimensionen zur Bestimmung der 
Form der Arbeitskontrolle dar. Sie dienen auch in dieser Studie als zentrale 
Untersuchungsdimensionen: 


Aufgabenorganisation 
- Kontrollstruktur 
- Kooperationsbeziehungen 


Interne und externe Arbeitsmärkte 


In jedem Aktivitätsfeld bündeln sich bestimmte Aktivitäten des Managements. 
Für welche strategische Orientierung die eine oder andere Art der Ausführung 
der Managementaktivitäten schließlich spricht, kann über die Ausprägungen 
der sogen. strategischen Dimensionen jedes Feldes bestimmt werden. Zusammen 
betrachtet, geben sie Aufschluss über die strategische Orientierung des Manage- 
ments in jedem dieser Aktivitätsfelder. 

Im folgenden sollen kurz die Aktivitätsfelder, die darin gebündelten Aktivi- 
täten sowie deren strategische Dimensionen näher beschrieben werden. Eine 


Übersicht gibt die Tabelle 4.1 (S. 71). 


4.3.1 Aufgabenorganisation 


Das Feld der Aufgabenorganisation beinhaltet die Aktivitäten des Managements, 
mit denen die Gesamtaufgabe der Produktion in einzelne Arbeitsaufgaben der 
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Strategische Direkte Kontrolle (restriktive Kontrolle) vs. Verantwortliche Autonomie (permissive Kontrolle) 
Ausrichtung 
Aktivitätsfelder Aufgabenorganisation Kontrollstruktur Kooperationsstrukturen | Arbeitsmarktbeziehun- 


Aktivitäten 


Art und Weise der 
Arbeitsaufträge 


Ebenen der Kontrolle: 


Gestaltung der 
Kommunikation auf 


gen 


» Rekrutierung 


» Anleitung und Ebene der » Aus- und Weiterbildung 
Arbeitsmethoden Anweisung 
+ Überwachung * Teams » Aufstieg 
Zeitplanung und » Evaluation * Standorte 
Organisationsstruktur + standortübergreifenden » Freisetzung 
Phasen der Kontrolle: Zusammenarbeit 
Technische Hilfsmittel von Beschäftigten 
Arbeitsbeginn, -prozess 
und -ergebniss 
Strategische + Aufgabenlänge » Dichte und Genauigkeit * Intensität der » Abhängigkeit von 
Dimensionen » Abwechslung der » Formalisierungsgrad Kommunikation Beschäftigten 
Arbeitsaufgaben » Fokus der Kontrolle: » Form der » Gewährung von 


Kommunikation 
(technisch/persönlich) 
» Kooperative vs. 


+ Kreativitätsanforderung 
der Aufgaben 


Prozess- oder Ergebnis- 
kontrolle 
» Art der Anreizstruktur 


Beschäftigungssicherheit 
für Beschäftigte 
konkurrenzförmige 
Beziehungen 


Abbildung 4.1: Managementstrategien, Aktivitätsfelder und strategische Di- 
mensionen (leicht verändert nach Friedman 1990b, $.189) 


Beschäftigten heruntergebrochen und in einen arbeitsteiligen Ablauf integriert 
wird. 

Genauer berücksichtigt werden dabei die Art und Weise, in der Arbeitsauf- 
träge erteilt werden, die Arbeitsmethoden, die Zeitplanung der Produktion, die 
Strukturen der Organisation, sowie die zur Verfügung stehenden Werkzeuge und 
Maschinen (Friedman 1987, S. 112). 

Mit der „Art der Auftragserteilung“ wird gefasst, wie in einem Unternehmen 
die Aufgaben für die Beschäftigten - im Fall dieser Studie also der Softwareent- 
wickler - definiert und verteilt werden. Dies kann durchaus variieren. So können 
sich Unternehmen, bzw. die Ansätze des Managements dahingehend unterschei- 
den, wieviel Mitsprachemöglichkeiten die Beschäftigten bei der Definition der 
Arbeitsaufgaben haben, welchen Umfang und Komplexitätsgrad die verteilten 
Aufgaben haben und ob die Arbeitsaufgaben an eine Gruppe von Personen verge- 
ben oder einzeln zugewiesen werden. Wichtig ist dabei auch, wie weitreichend 
die Arbeitsaufgaben vorspezifiziert sind, da dieser Punkt entscheidend darüber 
bestimmt, inwiefern die Beschäftigten eigene Problemlösungskompetenzen ein- 
bringen müssen bzw. können. 

Die „Arbeitsmethoden“ in der Produktion beziehen sıch auf die realen Arbeits- 
abläufe im Betrieb, also auf die Frage wie z.B. im Falle der Softwareentwicklung 
eine Spezifikation für ein Softwareprogramm in ein lauffähiges Programm um- 
gesetzt wird. Angesprochen sind damit die unterschiedlichen im Arbeitsprozess 
involvierten Rollen und deren Form der Zusammenarbeit. Interessant sind in 
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dieser Hinsicht aber auch Fragen der Gestaltung der Arbeitsplatze und -zeiten, 
soweit sich diese auf die Art der Aufgabenbearbeitung der Entwickler auswirken. 

Mit den Aktivitäten hinsichtlich der „Zeitplanung und Organisationsstruktu- 
ren“ wird die formale Seite der Aufgabenbearbeitung abgedeckt. Hier werden 
die Strukturen des Unternehmens und der Teams berücksichtigt: Wie sind die 
Projekte aufgebaut, wieviele Hierarchiestufen gibt es und welche Tätigkeitsprofile 
sind damit verbunden? Selbstverständlich gehört auch die zeitliche Planung der 
Arbeitsprozesse in diese Kategorie, im Falle dieser Studie also Fragen, wie z.B. 
die einzelnen Phasen der Softwareentwicklung zeitlich geregelt sind. Gerade 
auch im Hinblick auf die Untersuchung der Arbeitskontrolle beim indischen IT- 
Dienstleister sind an diesem Punkt die zeitlichen Vereinbarungen, die zwischen 
Dienstleister und Kunde in Bezug auf die Arbeitsaufgaben getroffen werden, von 
entscheidender Bedeutung. 

Schließlich hängt die Gestaltung der Arbeitsaufgaben auch an den vorhandenen 
„Werkzeugen und Maschinen“. Dieser Aspekt verweist auf die im Arbeitsprozess 
genutzten technologischen und maschinellen Grundlagen, hier also die vorfindli- 
chen informationstechnischen Infrastrukturen, wie z.B. die von den Entwicklern 
zu nutzenden Programmierumgebungen und sonstigen technischen Hilfsmittel 
(Zentrale Datenbanken, computergestütztes Wissensmanagement, Kommunika- 
tionsmedien, etc.). 


Alle genannten Aktivitäten dieses Feldes bestimmen demnach auf die eine oder 
andere Weise über die Formen der Arbeitsaufgaben der Beschäftigten und die 
Art und Weise, in der diese von jenen bearbeitet werden. Um die Aktivitäten 
im Hinblick auf die verfolgte Strategie des Managements zu interpretieren, wer- 
den die Aktivitäten des Managements auf die Ausprägungen der strategischen 
Dimensionen dieses Feldes bezogen. Als strategische Dimensionen des Feldes der 
Aufgabenorganisation werden bei Friedman die drei Dimensionen Aufgabenlänge, 
Aufgabenvielfalt und die kreativen Anforderungen der Arbeitsaufgaben berück- 
sichtigt (Friedman 1987, S.115). „Kreativ“ meint in diesem Zusammenhang, dass 
eine Arbeitsaufgabe von den Beschäftigten eigene Problemlösungskompetenzen 
erfordert, weil die Aufgabenstellung neu ist und/oder (noch) keine Vorgaben für 
deren Erledigung existieren, so dass Probleme selbständig gelöst werden müssen. 

In diesem begrifflichen Rahmen gefasst, wird erwartet, dass sich Strategien der 
„direkten Kontrolle“ und Strategien, die eher dem Leitbild „der verantwortlichen 
Autonomie“ folgen, in diesen strategischen Dimensionen unterschiedlich dar- 
stellen. So sollte eine Kontrollstrategie, die eher in Richtung „direkte Kontrolle“ 
tendiert, eher routinisierte, wiederkehrende und kurztaktige Arbeitsaufgaben 
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präferieren, die den einzelnen Beschäftigten wenig kreative Anforderungen abver- 
langen. Eine Strategie der „verantwortlichen Autonomie“ hingegen sollte eher auf 
die individuellen Lösungsfähigkeiten der Beschäftigten abzielen und ihnen daher 
Zeit und Handlungsspielräume bei der Bearbeitung einräumen, die sich dann in 
grob spezifizierten und langfristig terminierten Arbeitspaketen niederschlagen 
sollten, die von hohen kreativen Ansprüchen gekennzeichnet sind. 


4.3.2 Kontrollstruktur 


Das zweite Aktivitätsfeld - Kontrollstruktur - bezeichnet einen Kernbereich der 
vom Management verfolgten Strategien. 

Um an dieser Stelle begriffliche Verwirrung zu vermeiden, muss eine Anmer- 
kung zur Verwendung des Kontrollbegriffes bei Friedman gemacht werden. So 
wird der Begriff in der vorgestellten Konzeption doppelt verwandt: Einerseits soll 
die Strategie der betrieblichen Kontrolle über die Analyse von Aktivitätsfeldern 
bestimmt werden, wobei andererseits die „Kontrollstruktur“ gleichzeitig ein 
eigenes Aktivitätsfeld bezeichnet. Die Verwirrung resultiert aus einer doppelten 
Bedeutung des Begriffs der Kontrolle, der für die Labour Process Theory (LPT) 
generell typisch ist. So unterscheidet auch Thompson (1989) zwischen „gene- 
ral“ und „immediate control“ über Arbeitsprozesse. Auf der einen Seite bezieht 
sich der Begriff der Kontrolle auf den generellen Kontrollimperativ, der aus den 
spezifischen Bedingungen des kapitalistischen Arbeitsprozesses entsteht, und 
beinhaltet, dass das Management auf die eine oder andere Weise den Arbeitspro- 
zess beherrschen und gestalten muss (vgl. auch Voß und Pongratz 1998). Auf der 
anderen Seite („immediate control“) soll mit dem Begriff der Kontrollstruktur 
jedoch auch die konkrete Involviertheit des Managements in den Arbeitsablauf 
angesprochen werden. So gefasst, bedeuten auch permissive Kontrollstrategien 
eine generelle Kontrolle des Arbeitsprozesses durch das Management, diese ist 
lediglich im Arbeitsprozess weniger präsent. Denn die Implementierung dieser 
Form der Aufgabenorganisation ist ja ihrerseits Ergebnis gestaltender Maßnah- 
men des Managements. Das Aktivitatsfeld der Kontrollstruktur bezieht sich 
folglich auf diesen konkreten Aspekt der Kontrolle im Arbeitsprozess. 


Im Feld der Kontrollstruktur werden unterschiedliche Ebenen und Phasen der 
Kontrolle unterschieden. 

Die drei Ebenen der Kontrollstruktur sind Anleitung und Anweisung, Uberwa- 
chung und Evaluation von Arbeitsschritten (Friedman 1987, $.116). Auch wenn 
für gewöhnlich alle 3 Ebenen vom Management strategisch bearbeitet werden, 
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lassen sich doch auch Unterschiede in der Schwerpunktsetzung ausmachen. Wenn 
ein Unternehmen z.B. den Schwerpunkt auf die möglichst detaillierte Anleitung 
und Anweisung der Beschäftigten legt, kann damit ein weniger straffes Überwa- 
chungssystem ausgeglichen werden. Umgekehrt kann eine enge Überwachung des 
Prozesses auch hohen Aufwand bei der Evaluation ersparen. Dementsprechend 
können diese drei Ebenen der Kontrolle auch substitutiv zueinander stehen. 

Die Aktivitäten des Managements im Feld der Kontrollstruktur können sich je- 
doch nicht nur auf unterschiedliche Ebenen, sondern zudem auf unterschiedliche 
Phasen des Kontrollzyklus richten. Unter Kontrollzyklus wird verstanden, dass 
jeder arbeitsteilige Arbeitsprozess grundsätzlich aus den (wiederkehrenden) Pha- 
sen des Arbeitsbeginns, -prozesses und -ergebnisses besteht, die vom Management 
auf den genannten Ebenen jeweils kontrolliert werden können. 


Die strategischen Dimensionen des Feldes der Kontrollstruktur bestehen in der 
Dichte und Genauigkeit von Anweisung, Überwachung und Beurteilung. Diese 
Dimension zielt also schwerpunktmäßig auf die Erfassung des Handlungsspiel- 
raums der Beschäftigten ab. Weitere strategische Dimensionen sind der Formali- 
sierungsgrad der Kontrolle, die Frage, ob vornehmlich Arbeitsergebnisse oder 
-prozesse überwacht werden, sowie die im Betrieb präferierte Anreizstruktur (vgl. 
Friedman 1987, $.117). 

Für restriktive Kontrollstrategien wird erwartet, dass die Kontrollstruktur 
möglichst kleinschrittige und detaillierte Anweisungen und engmaschige Uber- 
wachungsmechanismen beinhaltet, sowie schwerpunktmäßig mit einer präzisen 
Überwachung der Arbeitsprozesse einhergeht. Die präferierte Anreizstruktur be- 
steht hier erwartungsgemäß im Bestrafen von Abweichungen vom vorgegebenen 
Vorgehen‘. 

Permissive Kontrollstrategien werden hingegen eher weniger detaillierte Vor- 
gaben hinsichtlich der Arbeitsaufgaben und auch eine ebenfalls weniger strikte 
Überwachung beinhalten, um die Selbstorganisation und Initiative der Beschäf- 
tigten so wenig wie möglich zu hemmen. Statt dessen setzen permissive Kontroll- 
strategien, so die Erwartung, cher auf eine Überwachung der Arbeitsergebnisse 
am Ende der Arbeitsprozesse bzw. einzelner Abschnitte der Arbeitsabläufe. Ein 
derartiger Ansatz setzt demnach cher bei den beteiligten Personen an, indem 


* Es muss zum besseren Verständnis an dieser Stelle noch einmal erwähnt werden, dass es sich 
hier um sehr zugespitzte Annahmen über Zusammenhänge handelt. So kann natürlich auch 
selbst in sehr eng überwachten Arbeitsformen, wie der Fließbandarbeit auch mit positiven 
Leistungsanreizen gearbeitet werden, die dann entsprechend negative Anreize ergänzen und 
ausgleichen. 
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die individuell gezeigte Arbeitsleistung über die gelieferten Ergebnisse, z.B. in 
Form von Zielvereinbarungsgesprächen und/oder regelmäßig stattfindenden Mei- 
lensteinen überwacht und gemessen wird. Um freiwillige Leistungsbereitschaft 
und selbstständiges Arbeiten zu befördern, beinhalten die Anreizstrukturen bei 
permissiven Kontrollstrategien idealer Weise primär positive Anreize, z.B. in 
Form von Bonuszahlungen bei besonderen Leistungen. 


4.3.3 Kooperationsstrukturen 


Das Aktivitätsfeld der Kooperationsstrukturen beinhaltet „die Förderung, die 
Behinderung und das Organisieren der Kommunikation“ (ebd., $.120) zwischen 
verschiedenen Gruppen von Beschäftigten. 

Das verweist auf die Herstellung von Kern- und Randbelegschaften, die unter- 
schiedlich kontrolliert werden, wobei die Existenz der einen Gruppe eine schär- 
fere Kontrolle der anderen erst ermöglicht. Zu denken ist an Konstellationen, in 
denen die eher nach verantwortlicher Autonomie kontrollierte Kernbelegschaft 
über die Existenz einer großen Randbelegschaft, die auf den Kernbereich drängt, 
unter Druck gesetzt werden kann. 

Für Friedman ist dieses Aktivitätsfeld demnach stark an die Aufrechterhaltung 
von betrieblicher Herrschaft gekoppelt, und er untersucht es vor allem in Be- 
zug auf möglichen Arbeiterwiderstand. Dies ist zwar bei den hier untersuchten 
IT-Firmen - und vermutlich auch generell bei IT-Firmen und IT-Beschäftigten 
aufgrund deren traditionell niedrigem gewerkschaftlichen oder sonstwie kollekti- 
ven Organisierungsgrad - nicht so relevant, jedoch hat diese Dimension auch für 
die in dieser Studie behandelte Fragestellung einigen Erklärungswert. 

Dies betrifft etwa das Verhältnis, das die Firma zwischen den räumlich getrenn- 
ten Teilen des Projektteams (Onsite/Offshore) zu errichten bemüht ist: Lernen 
sich die Beschäftigten persönlich kennen oder sind es eher knapp gehaltene, for- 
malisierte Kontakte? Kommt es zu persönlichem Austausch und wie nehmen sich 
die beiden Gruppen gegenseitig wahr? Da es sich bei Offshoring-Konstellationen 
meist um Kooperationsstrukturen zwischen Hoch- und Niedriglohnstandorten 
handelt, stellen die Standorte jeweils auch eine Gefahr füreinander dar. Bei No- 
voProd z.B. beschweren sich einige indische Beschäftigte, dass die deutschen 
Beschäftigten unwillig seien, ihre Arbeit zu dokumentieren und ihr Wissen zu 
teilen, was zu schlechteren Ergebnissen auf indischer Seite führe. Gleichzeitig 
haben die deutschen Beschäftigten Angst, dass bald auch ihr Arbeitsplatz nach 
Indien verlagert wird. Da es sich in diesem Fall jedoch wirklich um ein transna- 
tionales Projektteam handelt, also beide Seite miteinander kooperieren müssen, 
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stellen solche Konkurrenzverhältnisse eine Gefahr für das Gelingen der Projek- 
te dar. Das Verhältnis, in das die beiden Standorte zueinander gesetzt werden, 
hat demnach großen Einfluss auf die Form der Zusammenarbeit und die Ko- 
operationsbereitschaft der Beschäftigten. Es darf daher erwartet werden - und 
die empirischen Ergebnisse stützen diese Vermutung - dass die Gestaltung der 
Kooperationsstrukturen zwischen dem deutschen und dem indischen Teil eines 
Projektteams ein wichtiges Feld für Managementaktivitäten in unseren beiden 
Sampleunternehmen darstellt. 

Doch auch über die reine Onsite-Offshore-Beziehung hinaus, ist die Art und 
Weise, in der das jeweilige Management Kooperationsbeziehungen zwischen den 
Beschäftigten fördert oder auch hemmt, von hohem Erkenntniswert. 

Wie Kontrolle sich gestaltet, hängt nicht zuletzt davon ab, in welches Verhältnis 
die verschiedenen Abteilungen und auch die einzelnen Beschäftigten eines Betrie- 
bes zueinander gesetzt werden und wie intensiv die Kooperationsbeziehungen 
zwischen den Entwicklern eines Teams sind - teamübergreifend und evtl. auch 
organisationsübergreifend (zu Beschäftigten bei Kunden- oder Partnerfirmen). 


Die strategischen Dimensionen des Feldes der Kooperationsstrukturen betreffen 
zum einen die Intensität der Kommunikation und die Form derselben (technisch, 
persönlich), und zum anderen die Art und Weise, in der Beschäftigtengruppen 
miteinander in Verhältnis gesetzt werden (kooperativ oder konkurrenzförmig). 

Es wird erwartet, dass restriktive Kontrollstrategien auch aufgrund der typi- 
schen Formen der Aufgabenorganisation weniger intensive Kommunikations- 
beziehungen erfordern, als dies bei permissiven Strategien der Fall ist. Werden 
Arbeitspakete detailliert vorgeschrieben und eng überwacht, ist das Maß der zur 
Bearbeitung nötigen Kommunikation eingrenzbar. Zudem würde man bei restrik- 
tiven Kontrollstrategien erwarten, dass die Kommunikation stark formalisiert 
und - sofern realisierbar - auch technisch gestützt stattfindet. 

Sind Arbeitspakete hingen weit spezifiziert und sind die Beschäftigten aufgeru- 
fen, eigene Lösungen zu finden, sollte der Grad der Kommunikation zwischen 
Beschäftigten im Team oder auch in anderen Abteilungen zunehmen, von denen 
Informationen eingezogen werden müssen und deren Kooperation erwünscht 
oder nötig ist. 

Für die vorliegende Studie sind diese strategischen Dimensionen zentral. Denn 
der Grad der Kommunikation und die Form derselben sind, sowohl im Hinblick 
auf die Beziehung zwischen einzelnen Abteilungen und Teams an einem Standort, 
als auch auf die Beziehung zwischen Standorten, eine wichtige Dimension bei 
der Gestaltung der räumlich verteilter Projektteams. Gilt IT-Arbeit gemeinhin 
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als schwierig exakt vorzuschreiben und im Ablauf eng zu überwachen, so werden 
gute Kommunikationsbeziehungen als wesentliche Voraussetzung der Arbeits- 
verausgabung angesehen. Gerade diese wird durch die räumliche Verlagerung 
erschwert. Zum einen natürlich ganz grundsätzlich durch die große Entfernung 
zwischen Standorten - zusätzlich erschwert durch unterschiedliche Zeitzonen, 
die das gemeinsame „Zeitfenster“ für direkte Kommunikation verkleinern - aber 
zum anderen auch durch die oft beschworenen kulturellen Unterschiede zwi- 
schen Beschäftigtengruppen an weit entfernten Standorten. Die Steuerung der 
Kommunikation zwischen den Standorten genießt demnach bei Verlagerungs- 
projekten hohe Priorität (vgl. z.B. BITKOM 2005). 


4.3.4 Arbeitsmarktbeziehungen 


Das Aktivitätsfeld der internen und externen Arbeitsmarktbeziehungen schließlich 
betrifft das Verhältnis des Betriebes sowohl zu den externen Arbeitsmärkten (von 
denen Beschäftigte rekrutiert und auf die sie wieder entlassen werden), als auch 
zu den internen Arbeitsmärkten, die Friedman als „Mechanismen innerhalb der 
Firma“ bezeichnet, „durch die den Arbeitern Positionen mit unterschiedlicher 
Bezahlung und Status zugewiesen werden“ (Friedman 1987, S. 118). 

Die Aktivitäten des Managements lassen sich in diesem Feld in Rekrutierung, 
Aus- und Weiterbildung, Aufstieg und Freisetzung unterteilen (ebd., S. 118). 

Erfasst wird also zunächst die Art und Weise, in der Unternehmen ihre Be- 
schäftigten rekrutieren. Hier können große Unterschiede dahingehend bestehen, 
nach welchen Kriterien die Unternehmen vorgehen und welche Zielgruppe sie 
anpeilen. Gerade im Hinblick auf die in dieser Studie untersuchten Betriebe im 
indischen Bangalore mit seinen umkämpften Arbeitskräften z.B. stellt sich das 
Problem, an eine ausreichende Zahl gut qualifizierter Arbeitskräfte zu kommen. 

Nach der Rekrutierung müssen Beschäftigte an das Unternehmen heran- und 
in die Arbeitsprozesse eingeführt werden. Dabei sind die Einarbeitungs- und in 
der Folge die Weiterbildungsaktivitäten von besonderer Bedeutung. Wie lange 
dauert es z.B., bis die neueingestellten Beschäftigten selbständig im Betrieb ar- 
beiten können und wie wird das nötige Wissen vermittelt? Hier bestehen enge 
Verbindungen zum Bereich der Aufgabenorganisation, denn enge, klar spezifizier- 
te Arbeitsaufgaben werden voraussichtlich wesentlich weniger Einarbeitungszeit 
und qualifikatorische Voraussetzungen erfordern, als weite, mehr den Problemlö- 
sungsfähigkeiten der Beschäftigten überlassene Arbeitspakete. 

Ebenfalls wichtig in diesem Feld sind die Karrierewege, die eng mit der Orga- 
nisationsstruktur des Betriebes zusammenhängen. Entscheidend sind hier neben 
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der Zahl an Hierarchiestufen auch die Beförderungsmodalitäten, also wer Einfluss 
auf etwaige Beförderungen hat und wie über solche entschieden wird. 

Der letzte Punkt betrifft schließlich den Umgang des Unternehmens mit 
Beschäftigten, die kündigen oder entlassen werden. Auch dies ist für die Un- 
tersuchung der indischen Betriebe aufgrund der hohen Fluktuationsraten am 
indischen Standort enorm wichtig. Zentral sind in dieser Hinsicht die Aktivitäten 
des Unternehmens, um Personalfluktuation zu vermeiden und Beschäftigte an 
das Unternehmen zu binden (vgl. dazu auch Mayer-Ahuja und Feuerstein 2008). 


Im Feld der internen und externen Arbeitsmarktbeziehungen betreffen die stra- 
tegischen Dimensionen den Grad der Abhängigkeit des Betriebes von den Be- 
schäftigten (bzw. bestimmten Beschäftigtengruppen) und das Ausmaß, in dem 
ein Betrieb bestrebt ist, sie an das Unternehmen zu binden. 

Die Abhängigkeit verweist auf die mögliche Ersetzbarkeit von Personen (ent- 
sprechend deren Qualifikationen und Erfahrung) und ist damit in hohem Maße 
von der verfolgten Aufgabenschneidung und den daraus resultierenden Quali- 
fikationsanforderungen, wie z.B. der Relevanz von betriebsspezifischem, bzw. 
Erfahrungswissen, abhängig. 

Eine hohe Abhängigkeit der Arbeitsabläufe von bestimmten (wenn nicht allen) 
Beschäftigten - wie dies für permissive Kontrollstrategien aufgrund der beson- 
deren Form der Aufgabenschneidung typisch ist - sollte dazu führen, dass die 
Bindung der Beschäftigten an den Betrieb für das Management hohe Relevanz be- 
sitzt und dass in dieser Hinsicht bestimmte Maßnahmen ergriffen werden müssen. 
Diese Maßnahmen können durchaus unterschiedlicher Art sein. Darunter wür- 
den z.B. bestimmte Sicherheitsgarantien, aber auch finanzielle oder symbolische 
Sonderzuwendungen fallen. Zentrales Feld für derlei Aktivitäten sind natürlich 
auch Fragen der Karrierewege und Beförderungen in einem Unternehmen. 

Eine Kontrollstrategie der direkten Kontrolle, die auf kleine Arbeitspakete 
ohne hohe kreative Anforderungen setzt, wird hingegen in geringerem Maße 
von bestimmten Beschäftigten oder -gruppen abhängig sein, eine Strategie der 
verantwortlichen Autonomie, die aufgrund der expliziten Nutzung individueller 
Problemlösungskompetenzen der Beschäftigten stark an Individuen gebunden 
ist. 

So sollten sich in den Dimensionen „Abhängigkeit des Betriebes von Beschäf- 
tigten“ und „Gewährung von Arbeitsplatzsicherheit“ wichtige Unterschiede 
zwischen diesen beiden Strategierichtungen festmachen lassen. 
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4.4 Reorganisationsmodi zwischen variierenden 
Internationalisierungswegen und indischem 
Arbeitsmarkt 


Mit diesem Kapitel endet der konzeptionelle Teil dieser Arbeit, und die Hypo- 
these dieser Studie kann nun genauer und exakter reformuliert werden. 

In Abgrenzung von den Vertretern der „Industrialisierungsthese“ geht diese 
Arbeit nicht von einem linearen und gleichmäßigen Trend der Industrialisierung 
von IT-Arbeit im Zuge der Internationalisierung der IT-Industrie aus. Vielmehr 
wird angenommen, dass sich in der IT-Industrie unterschiedliche Reorganisations- 
modi identifizieren lassen, die in ihrer Gestalt durch das Wechselspiel zwischen 
den spezifischen Internationalisierungswegen auf der einen und den Arbeitsmärkten 
der Zielstandorte auf der anderen Seite beeinflusst werden und unterschiedliche 
Formen der Arbeitsorganisation und -kontrolle beinhalten. 

In den folgenden Fallstudien werden zwei sehr unterschiedliche Varianten 
der Reorganisation von Arbeit in internationalisierten IT-Unternehmen näher 
beschrieben. Dabei wird sich zeigen, dass die Internationalisierung durchaus 
mit zunehmend restriktiven Formen der betrieblichen Kontrolle einhergehen 
kann, wie die Vertreter der Industrialisierungsthese unterstellen. Jedoch lässt 
sich anhand der Untersuchung des IT-Dienstleisters ServiceTec zeigen, dass diese 
„Industrialisierung“ der Arbeitsprozesse keineswegs als einfache Reaktion auf 
die Erfordernisse der globalen Produktionsprozesse zurückzuführen ist, son- 
dern ihrerseits Ausdruck eines „Synergieeffekts“ zwischen dem spezifischen 
Geschäftsmodell von IT-Dienstleistern und eines Umgangs mit den Eigenheiten 
des indischen Arbeitsmarktes ist. Es ist daher kein Zufall, dass die Vorreiter des 
„Global Delivery Model“ im Bereich der IT-Dienstleistungen gerade aus Indien 
stammen. 

Der Fall hingegen, an den bei der Rede von IT-Offshoring in der Regel am häu- 
figsten gedacht wird - die Verlagerungsaktivitäten westlicher [T-Unternehmen 
an entfernte Standorte - zeigt, dass international verteilte Software-Entwicklung 
nicht notwendigerweise „industrialisierte“ Arbeitsprozesse beinhalten muss. Viel- 
mehr prägen bei NovoProd nach wie vor viele traditionelle Formen auch am 
indischen Entwicklungsstandort die betriebliche Kontrollstrategie. Der Grund 
hierfür liegt in dem speziellen Internationalisierungsweg von Standardsoftware- 
Herstellern, der nicht nur der Standardisierung und Formalisierung der Ar- 
beitsprozesse Grenzen setzt, sondern auch Möglichkeiten bietet, den indischen 


80 Reorganisationsmodi 


Arbeitsmarkt in einer ganz anderen Weise organisatorisch zu bearbeiten, als 
ServiceTec dies vermag. 


Mit der Untersuchung eines deutschen Standardsoftware-Herstellers und eines 
indischen IT-Dienstleisters konzentriert sich die vorliegende Arbeit auf zwei 
wesentliche Arten der Verlagerung von IT-Arbeit aus den Hochlohnregionen 
der kapitalistischen Zentren in die Niedriglohnregionen der kapitalistischen 
Semi-Peripherie und damit auf zwei dominante Internationalisierungswege in der 
IT-Industrie: die Verlagerung mithilfe eines externen Dienstleisters, das sogen. 
Offshore-Outsourcing, und die unternehmensinterne Verlagerung an eine eigene 
Niederlassung, das sogen. Captive-Offshoring. Es konnte gezeigt werden, dass die 
für die Industrialisierung von IT-Arbeit als zentral erachtete Standardisierung 
und Formalisierung bei diesen beiden Varianten der Verlagerung einen unter- 
schiedlichen Fokus aufweist. Steht bei IT-Dienstleistern die Standardisierung und 
Formalisierung der Geschäfts- und Arbeitsprozesse im Mittelpunkt, so richten 
sich die Bemühungen von unternehmensintern verlagernden Standardsoftware- 
Herstellern vielmehr zentral auf Produkte, also möglichst modulare Produkt- und 
Prozessarchitekturen. Daraus ergeben sich erwartungsgemäß unterschiedliche 
Richtungen bzw. unterschiedliche Schwerpunkte der Reorganisationsbemühun- 
gen. 


Ist mit den variierenden Internationalisierungswegen in der IT-Industrie auch 
ein wesentliches Differenzierungsmerkmal zwischen den verschiedenen Reor- 
ganisationsmodi benannt, so bedeutet das nicht, dass sich die in den indischen 
Niederlassungen der beiden Unternehmen vorfindbaren Formen der Arbeitsor- 
ganısation und -kontrolle gänzlich durch diesen Einflussfaktor erklären ließen. 
Vielmehr, so wird sich in den folgenden Falldarstellungen zeigen, lassen sich die 
jeweiligen Reorganisationsmodi von Arbeit nur angemessen verstehen, wenn 
gleichzeitig auch der Einfluss des indischen Arbeitsmarktes auf diese berücksich- 
tigt wird. 

Mit Indien fokussiert diese Studie auf den weltweit gegenwärtig größten Off- 
shore-Standort für die Verlagerung von IT-Arbeit. Diese Eigenschaft macht den 
indischen Standort für die verlagernden Unternehmen zunehmend problematisch. 
Mit den hohen Fluktuationsraten des indischen Arbeitsmarktes und den damit 
verknüpften hohen Erwartungen der Beschäftigten hinsichtlich Karriereverläufen 
und Gehaltsentwicklung, die durch das arbeitsmarktinduzierte Machtpotential 
der Beschäftigten auch durchsetzungsfähig werden, sind zentrale Eigenschaften 
des indischen Arbeitsmarktes benannt, auf die beide Unternehmen sich jeweils 
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organisatorisch einstellen miissen. In Kapitel 3 wurde gezeigt, dass aus der Si- 
tuation auf dem Arbeitsmarkt z.T. widerspriichliche Herausforderungen fiir die 
IT-Unternehmen erwachsen, auf die mit unterschiedlichen organisatorischen 
Strategien reagiert werden kann. 

Wie sich in den folgenden Falldarstellungen noch genauer zeigen wird, ist 
sowohl die Art und Weise in der die Unternehmen jeweils vom indischen Ar- 
beitsmarkt beeinflusst werden, als auch die Art und Weise, in der versucht wird, 
mit diesem organisatorisch umzugehen, vom jeweils verfolgten Internationalisie- 
rungsweg abhängig, da diese unterschiedliche Chancen und Risiken im Umgang 
mit dem indischen Arbeitsmarkt begründen. 


Analysiert werden sollen die unterschiedlichen Reorganisationsmodi in den For- 
men der betrieblichen Arbeitskontrolle in den Offshore-Standorten. Es konnte 
gezeigt werden, dass sich die von den Vertretern der Industrialisierungsthese 
erwarteten Veränderungen in der Kontrolle von IT-Arbeit in der Begrifflichkeit 
Friedmans als ein Strategiewechsel von Strategien der „verantwortlichen Auto- 
nomie“ hin zu jenen Strategien fassen lässt, die eher dem Muster der „direkten 
Kontrolle“n folgen. 

Die Rede von unterschiedlichen Reorganisationsmodi impliziert die Erwar- 
tung, dass sich die Formen der betrieblichen Kontrolle in den beiden Unter- 
suchungsfällen als unterschiedliche Ausprägungen derselben Dimensionen der 
Arbeitskontrolle identifizieren lassen. Als zentrale Dimensionen der Arbeitskon- 
trolle werden in Anlehnung an Friedman die Aufgabenschneidung, die Kontroll- 
struktur, die Kooperationsstrukturen und die internen und externen Arbeitsmarkt- 
beziehungen herangezogen. Als Erwartung kann formuliert werden, dass sich die 
Reorganisationsmodi der beiden untersuchten Unternehmen in den genannten 
Dimensionen anhand der für jedes Feld definierten strategischen Dimensionen 
unterscheiden lassen. Als Ergebnis sind wesentlich unterschiedliche Formen der 
betrieblichen Kontrolle feststellbar. 

Die Darstellung 4.2 (S. 82) stellt den konzeptionellen Zugriff dieser Studie 
noch einmal zusammenfassend dar, bevor wir uns in den folgenden Kapiteln 
ausführlich den Formen der betrieblichen Arbeitskontrolle in den beiden Unter- 
suchungsbetrieben zuwenden. 

Dabei folgt die Gliederung der Fallstudien der vorgenommenen Dimensionierung 
der betrieblichen Kontrollformen. Für die beiden untersuchten Unternehmen 
werden die Aktivitäten des Managements in den vier zentralen Aktivitätsfeldern 
beschrieben, und anhand der feldspezifischen strategischen Dimensionen in ih- 
rem Bezug zur im Unternehmen dominierenden Kontrollstrategie analysiert. 
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Abbildung 4.2: Betriebliche Kontrolle zwischen Geschäfts- und Verlagerungs- 
modellen und indischem Arbeitsmarkt 


Jede Fallstudie endet mit einem zusammenfassenden Zwischenfazit, in dem die Er- 
gebnisse zu den Aktivitätsfeldern verknüpft und im Zusammenhang interpretiert 
werden. 

Entsprechend der zentralen Hypothese dieser Studie wird sich das Augen- 
merk bei der Beschreibung und Interpretation der Aktivitäten des Managements 
in jedem Aktivitätsfeld vor allem auf die Einflüsse richten, die dem Interna- 
tionalisierungsweg und dem damit zusammenhängenden Geschäftsmodell des 


Unternehmens bzw. der Situation auf dem indischen Arbeitsmarkt zugeschrieben 
werden können. 


5 „It’s like making a car“ - 
Kontrolle von Arbeit beim indischen 
IT-Dienstleister ServiceTec 


Mit ServiceTec wird im Folgenden ein Fall präsentiert, der sich in der Gestal- 
tung seiner international verteilten Erbringung von IT-Dienstleistungen durch 
eine sehr starke Standardisierung und Formalisierung der Arbeitsprozesse und 
eine extrem restriktive Form der Arbeitskontrolle auszeichnet. Damit entspricht 
der Fall Service Tec auf den ersten Blick zunächst weitgehend den Erwartungen 
der Vertreter der Industrialisierungsthese. Wie ich in der folgenden detaillierten 
Untersuchung der Kontrollstrategie ServiceTecs jedoch zeigen möchte, ist dieser 
spezielle Reorganisationsmodus Service Tecs das Ergebnis eines „Synergieeffekts“: 
Die vorfindbare Standardisierung und Formalisierung der Arbeitsprozesse bei 
Service Tec ist auf der einen Seite den Notwendigkeiten des von IT-Dienstleistern 
verfolgten Internationalisierungsweges geschuldet, auf der anderen Seite stellt 
dieses Vorgehen jedoch auch einen wirksamen organisatorischen Umgang mit 
den hohen Fluktuationsraten des indischen Arbeitsmarktes dar. Beide Aspekte 
verstärken sich gegenseitig und treiben die Standardisierung und Formalisierung 
der Arbeitsprozesse voran. Werden die indischen IT-Dienstleister in der Literatur 
häufig als Vorreiter der Etablierung globaler Produktionsprozesse im Bereich der 
IT-Dienstleistungen angesehen und deren „Prozessorientierung“ als entscheiden- 
der Wettbewerbsvorteil hervorgehoben (vgl. z.B. Boes u. a. 2007, Athreye 2005b), 
so zeigt sich, dass diese Eigenschaft mehr dem indischen Herkunftsstandort ge- 
schuldet ist, als reiner Ausdruck der fortschreitender Internationalisierung zu 
sein. 

Die Falldarstellung gliedert sich in die folgenden Schritte: nach einem kurz- 
en Kapitel mit näheren Informationen zum Profil des Unternehmens (5.1) soll 
anhand der Darstellung des von ServiceTec verfolgten Geschäftsmodells näher 
beschrieben werden, wie die Standardisierung und Formalisierung der Arbeitspro- 
zesse bereits durch die globale Arbeitsteilung zwischen den vor Ort beim Kunden 
und den in den Offshore-Entwicklungszentren arbeitenden Beschäftigten, so- 
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wie die für IT-Dienstleister typische Form der Kundenbindung gefördert wird 
(5.2). Die anschließende detaillierte Untersuchung der betrieblichen Kontroll- 
strategie bringt diese Einflüsse dann mit denen des indischen Arbeitsmarktes 
zusammen und zeigt anhand der detaillierten Untersuchung der vier zentralen 
Aktivitätsfelder, wie sich diese beiden Einflussfaktoren gegenseitig verstärken 
und die Arbeitsprozesse in der Folge stark standardisiert und formalisiert werden 
6.3). 


5.1 Das Profil von ServiceTec 


Service Tec ist eines der großen indischen IT-Dienstleistungsunternehmen, die 
in den letzten Jahren durch enorme Wachstumsraten sowohl der Umsätze als 
auch der Beschäftigtenzahlen aufgefallen sind. Der Umsatz ServiceTecs wuchs 
in den letzten Jahren mit z.T. weit über 30% auf über 4 Mrd. US-Dollar im Jahr 
2008. Die Zahl der weltweit Beschäftigten des Unternehmens wuchs alleine in 
den Jahren von 2002 bis 2008 rasant von ungefähr 10.000 auf über 90.000 an!. 
Der Großteil der Beschäftigten arbeitet in den indischen Entwicklungszentren 
ServiceTecs. 

ServiceTec bietet seinen Kunden die volle Bandbreite an IT-Dienstleistungen: 
von relativ einfachen Support- und Maintenance-Projekten, über Business Process 
Management, Beratungs- und Implementierungsprojekte, Test- und Integrations- 
arbeiten, bis hin zu komplexeren Forschungs- und Entwicklungsprojekten zur 
Herstellung von individuellen Softwareprodukten. Den Schwerpunkt der Aktivi- 
täten bildet dabei der Bereich der Entwicklung und Wartung von Software, auf 
diesen Bereich entfallen knapp 45% des Gesamtumsatzes ServiceTecs. 

Historisch ist ServiceTec vor allem durch Kunden in den USA gewachsen. 
Dominierte in den Anfängen der Firmengeschichte vor allem das die Entsendung 
indischer Programmierer in die USA das Geschäft von ServiceTec, so begann 
ServiceTec nach der Verschärfung der US-amerikanischen Visa-Regularien, die 
vor allem die indischen IT-Fachkräfte traf?, mit einem groß angelegten Aufbau 
von Offshore-Kapazitäten, um zukünftig Arbeiten für amerikanische Kunden 
von Indien aus zu erbringen. 

Auch gegenwärtig entfällt noch der Großteil des Firmenumsatzes auf Projekte 
mit amerikanische Kunden. Erklärtes strategisches Ziel der letzten Jahre ist es 


1 Alle Zahlenangaben sind dem aktuellen Geschäftsbericht des Unternehmens entnommen. 
? Nach einer Studie der Deutschen Bank gingen 43% der zwischen Oktober 1999 und Februar 
2000 gewährten H1B Visa an indische IT-Fachkräfte (Deutsche Bank Research 2005, S.8) 


Das Profil von Service Tec 85 


jedoch, die Abhängigkeit vom amerikanischen Markt und dessen Konjunktur- 
schwankungen durch Erschließung weiterer Absatzmärkte zu mindern. Diese 
Bemühungen waren in den letzten Jahren durchaus von Erfolg gekrönt - so sank 
der Anteil der amerikanischen Kunden am Unternehmensumsatz in den letzten 
Jahren kontinuierlich: von noch knapp 75% im Jahr 2003 auf knapp 60% im 
Jahr 2008. Gleichzeitig stieg die Bedeutung anderer Regionen - hier vor allem 
Europa - kontinuierlich an: waren es 2003 noch knapp unter 20%, so lag der 
Anteil Europas am Gesamtumsatz 2008 bereits bei knapp unter 30%. Dazu muss 
jedoch gesagt werden, dass diese positive Entwicklung in Europa gegenwärtig 
hauptsächlich durch Geschäfte in Großbritannien getragen wird. Kontinentaleu- 
ropa gilt (übrigens für alle indischen IT-Dienstleistungsunternehmen; Pohl und 
Onken 2003, vgl. S20f) bisher nach wie vor als schwer zu erschließen, jedoch wird 
der kontinentaleuropäische - und dort vor allem auch der deutsche - IT-Markt 
als der zentrale Wachstumsmarkt der Zukunft gesehen, so dass strategisch der 
Ausbau der geschäftlichen Aktivitäten in diesen Regionen für ServiceTec große 
Priorität genießt. 

Die Kunden von ServiceTec sind regionstibergreifend in erster Linie Grof- 
unternehmen aus den Bereichen Banken und Versicherungen (knapp 38% des 
Umsatzes), Telekommunikation (ca. 20% des Umsatzes) und der verarbeitenden 
Industrie (knapp 15% des Umsatzes). 

Im Bereich der IT-Dienstleistungen konkurriert ServiceTec nicht nur mit den 
anderen indischen IT-Dienstleistern, sondern auch mit den die Branche lange Zeit 
dominierenden, vorwiegend amerikanischen, globalen IT-Dienstleistungsunter- 
nehmen wie z.B. IBM und Accenture, die mittlerweile ebenfalls Entwicklungszen- 
tren in Niedriglohnregionen wie Indien aufgebaut haben, um den Kostenvorteil 
der indischen Unternehmen zu kontern. Grundsätzlich kann für den IT-Dienst- 
leistungsmarkt konstatiert werden, dass es sich um einen Nachfragemarkt handelt, 
auf dem, verstärkt durch die zunehmende internationale Konkurrenz (durch die 
neuen Anbieter aus Niedriglohnregionen wie Indien), ein enormer Kostendruck 
herrscht. Die Reduzierung der Produktionskosten für IT-Dienstleistungen ist 
dabei einerseits das Motiv für das Offshore-Outsourcing durch die Anwender- 
unternehmen, treibt diese Entwicklung andererseits aber auch voran, da die 
Anbieter z.B. aus Indien damit neue Kostenstandards setzen, denen sich auch 
westliche IT-Unternehmen wie IBM, Accenture u.a. stellen müssen (vgl. Boes u. a. 
2006, Kämpf 2008). 
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5.2 ServiceTecs globales Geschäftsmodell 


Als Anbieter von Offshore-Outsourcing-Dienstleistungen ist ServiceTec grund- 
sätzlich international - wenn auch anfänglich schwerpunktmäßig auf den ameri- 
kanischen Markt - ausgerichtet. Schon seit Ende des „bodyshopping“ sind bei 
ServiceTec internationale Leistungserbringungsstrukturen auffindbar, die mit 
der Zeit ausgeweitet und weiterentwickelt worden sind. 

Das dabei von ServiceTec verfolgte Geschäftsmodell entspricht dem (in der 
Literatur) indischen IT-Dienstleistern zugeschriebenen „Global-Delivery-Model“ 
und integriert somit systematisch Aktivitäten im Onsite-, Offshore- und neuer- 
dings auch Nearshore-Bereich. Onsite bezeichnet dabei den jeweiligen Nahbereich 
des Kunden, ist also je nach Kunde unterschiedlich, ist jedoch gemeinhin in den 
Regionen Nordamerikas und Europas, den Hauptabsatzmärkten ServiceTecs, 
angesiedelt. Der Offshore-Bereich bezeichnet primär die großen Entwicklungs- 
zentren in Indien. Zunehmend zählen aber auch weitere Niedriglohnregionen 
dazu, in denen ServiceTec beginnt, weitere Entwicklungszentren aufzubauen. 
Der Nearshore-Bereich ist in Service Tecs Geschäftsmodell recht neu. Darunter 
werden eigene Entwicklungskapazitäten in kundennahen Regionen gefasst. In Be- 
zug auf Europa sind dies Standorte in osteuropäischen Ländern, in den USA sind 
es zwar Entwicklungszentren in den USA, aber nicht direkt beim Kunden. Diese 
Zentren sind jedoch nicht in allen Projekten Service Tecs involviert, während alle 
im Rahmen dieser Studie untersuchten Projektteams über ein Onsite- und ein 
Offshore-Projektteam verfügten. 

Jedem dieser Standorte kommt in ServiceTecs Geschäftsmodell ein spezifisches 
Tätigkeitsprofil zu: er erfüllt bestimmte Aufgaben in der Projektabwicklung. Ein 
Vertreter des höheren Managements von ServiceTec beschreibt die Arbeitsteilung 
in der Projektabwicklung folgendermaßen: 


„I mean, basically, if you look at it in a hunter-farmer model: that BDMs 
[Business Development Manager - PF] are the people, who go hunt for 
the business, Engagement Managers are the people, who would do try and 
grow that business and then you have the delivery organization, who will 
basically run the business.“ (SI15)? 


Die drei wesentlichen Bereiche sind also der Vertriebsbereich (Sales mit den zu- 
ständigen Business Development Managern, kurz BDM), die Kundenbetreuung 


3 Alle Aussagen werden unter Bezugnahme auf die Aufstellung der geführten Interviews in Tabelle 
8.1 (S. 291) im Anhang zitiert. 
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(vertreten durch die jeweiligen Engagement Manager) und der Entwicklungsbe- 
reich (Delivery), der die jeweilige Leistung letztendlich erbringt. 

Der Vertriebsbereich wird in diesem Fall als eine Art Jäger („hunter“) verstan- 
den. Die zuständigen BDM versuchen, potentielle Kunden zu identifizieren und 
zu kontaktieren. Wenn dieser Kontakt gelungen ist und es ein erstes Einverständ- 
nis von Seiten des Kunden gibt, gibt der zuständige BDM den Kunden an einen 
sogenannten Engagement Manager im Bereich des Kundenmanagements weiter. 
Dieser ist im folgenden für die Durchführung des Projektes mit dem Kunden 
verantwortlich und versucht zudem, den Kunden weiter auszubauen, d.h. weitere 
Projekte für Service Tec zu akquirieren, daher auch die Bezeichnung als „farmer“. 
Die Erbringung der Leistung, im Sinne der faktischen Programmierung, obliegt 
dem Delivery-Bereich. Hier werden die je nach Projekt gewünschten Leistungen 
erbracht‘. 


Regional verteilen sich die Bereiche wie folgt: Die Beschäftigten des Vertriebs 
und die Kundenbetreuer sind vollständig Onsite, also in der Region des jewei- 
ligen Kunden angesiedelt. Sie arbeiten in den zahlreichen Vertriebsbüros, die 
ServiceTec mittlerweile weltweit aufgebaut hat. Diese Vertriebsbüros richten 
sich ganz nach dem Geschäftsaufkommen, variieren also auch hinsichtlich Größe 
und Personalstärke. So war der für Deutschland zuständige Vertriebsleiter in den 
ersten Jahren zunächst auf sich allein gestellt und auch später folgte ServiceTec 
mit seinen Büros in Deutschland einzelnen Kunden. Die positive Geschäftsent- 
wicklung in Deutschland hat in den letzten Jahren jedoch die Errichtung eines 
eigenen zentralen Vertriebsstandortes möglich und nötig gemacht. 

Im Delivery-Bereich ist die regionale Verteilung hingegen etwas komplizierter. 
Zwar befindet sich der Delivery-Bereich grundsätzlich in den großen Entwick- 
lungszentren (zumeist) Indiens, jedoch wird ein kleiner Teil des Delivery-Bereichs 
in der Projektabwicklung auch Onsite beim Kunden eingesetzt. Mit dieser Auf- 
teilung geht auch eine Arbeitsteilung innerhalb des Delivery-Bereichs einher. 
Ein Projektmanager beschreibt die Aufgaben des Onsite-Teils des Projektteams 
folgendermaßen: 


„In the onsite typically we do the work which requires customer interaction, 
the requirement analysis. [...] Because this is when you need to interact 
with the customer. So the folks, they work as a link between the customer 


* Bei reinen Beratungsprojekten kann es sein, dass es sich nur um Onsite-Aufgaben handelt. Die 
meisten Projekte ServiceTecs liegen jedoch, wie oben erwähnt, im Bereich der Entwicklung und 
Anpassung von Software für Kunden. Bei diesen Projekten gibt es dann auch die geschilderte 
Trennung der Aufgaben in Beratung/Planung und Programmierung/Codierung. 
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and ServiceTec. So this is where the criticality of the onsite comes in the 
picture. They are the link and they are also the link between the distance. 
I mean, if I can talk about onsite and offshore - it is a distance, a person 
sitting in Germany and sitting in Bangalore.“ (SI6) 


Die Beschaftigten beim Kunden bilden also die Schnittstelle zum Offshore- 
Bereich. Es sind auch Personen aus dem Delivery-Bereich, führen aber spezi- 
elle Tätigkeiten durch, für die der direkte Kontakt zum Kunden unerlässlich 
ist. Sie agieren vor Ort zusammen mit dem jeweiligen Engagement Manager, 
der für den Kunden zuständig ist. Der Engagement Manager ist jedoch in erster 
Linie für den geschäftlichen Teil zuständig, die technische Verantwortung liegt 
beim Projektmanager des Onsite-Teams aus dem Delivery Bereich, der auch als 
„Onsite-Coordinator“ bezeichnet wird. Der wesentlich größere Teil des Delivery- 
Teams befindet sich in den Offshore-Entwicklungszentren und ist dort für die 
Erbringung eben solcher Tätigkeiten zuständig, für die direkter Kundenkontakt 
nicht nötig ist. Die für das „Global Delivery Model“ typische Trennung von 
kundennah und kundenfern zu erbringen Tätigkeiten (siehe Kapitel 2.1 ) verläuft 
bei ServiceTec also nicht nur zwischen Vertrieb, bzw. Kundenbetreuung und 
Entwicklungsbereich, sondern auch innerhalb des Entwicklungsbereiches selbst. 


Die konkrete Form der Arbeitsteilung, sprich die Tätigkeitsprofile Onsite und 
Offshore sowie das zahlenmäßige Verhältnis der Mitarbeiter in den beiden Be- 
reichen, unterscheidet sich dabei zwischen den verschiedenen von ServiceTec 
durchgeführten Projektarten. 

Bei ServiceTec gibt es grob zwei typische Arten von Projekten. Einerseits 
handelt es sich um Maintenance-Projekte, also Projekte zur Wartung von beim 
Kunden bereits genutzten Programmen oder Systemen, seien sie von Service- 
Tec selbst entwickelt oder nicht. Andererseits gibt es Entwicklungsprojekte zur 
Erstellung kundenspezifischer Software-Lösungen, meist als Erweiterung oder 
Modifikation bestehender IT-Infrastrukturen oder verwandter Standardsoftware. 

Maintenance-Projekte, also Projekte, die die Wartung und Aufrechterhaltung 
bestehender IT-Infrastrukturen zum Ziel haben, seien dies ganze Systeme, ein- 
zelne Applikationen oder Internetportale, bilden mit 25% des Gesamtumsatzes 
neben Entwicklungs- und Implementierungsprojekten einen der größten Ge- 
schäftsbereiche ServiceTecs. Ein Projektmanager von ServiceTec differenziert 
dabei zusätzlich zwischen 3 verschiedenen Arten von Maintenance-Projekten: 
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„Normally we do three kinds of maintenance. One is the preventive main- 
tenance, which is like, you go and find out the problem beforehand and 
attack the problem, beforehand. And then we do the production support 
and bug-fixes, where we support the applications, that are already there in 
production. And lastly the enhancements to the existing application, where 
the business identifies the enhancements to business process or sometimes 
the government implants some new rules, which need to be enhanced in 
the system.“ (SI3) 


Die im Rahmen der vorliegenden Studie untersuchten Projektteams im Mainte- 
nance-Bereich waren alle im Bereich „Production support and bug fixing“ mit 
leichten Übergängen zum „Enhancement“ angesiedelt. Sie sind daher gemeint, 
wenn im Folgenden von Maintenance-Projekten gesprochen wird. 

Maintenance-Projekte sind kontinuierliche Projekte (wenngleich Wartungsver- 
träge natürlich auch zeitlich beschränkt sein können). Die zu wartende Software 
befindet sich in Benutzung durch die Anwender, und ServiceTec hat die Aufga- 
be, anfallende Probleme oder Fehler zu beseitigen. Der Arbeitsablauf in einem 
solchen Projekt kann grob in folgende Phasen aufgeteilt werden: 

Angestoßen wird der Prozess durch eine Fehlermeldung der Anwender (meist 
Mitarbeiter des Kundenunternehmens). Z.B. sind bestimmte Funktionen einer 
Applikation fehlerhaft oder unvollständig oder erfolgen nicht in der gewünschten 
Form. Diese vom Kunden kommenden Fehlermeldungen erreichen zunächst 
den sogen. „Onsite-Coordinator“. Hierbei handelt es sich um den für das Pro- 
jekt verantwortlichen Projektmanager des Onsite Delivery-Teams. Dem Onsite- 
Coordinator und seinem Team obliegt in der anschließenden Phase die Analyse 
und Klärung des Problems. Da die Fehlermeldungen der Anwender oft recht 
unspezifisch und ungenau sind, müssen in den meisten Fällen genauere Infor- 
mationen zum Defekt recherchiert werden, z.B. wann genau er auftritt, wie er 
sich äußert, usw. Dazu gehört auch eine Angabe über das gewünschte Verhalten 
der Applikation und die Priorität des Defekts, die letztlich über die zeitlichen 
Anforderungen der Problemlösung entscheidet. Diese Schritte werden in enger 
Kooperation mit dem Kunden durchgeführt. 

Eine solcherart genauer spezifizierte Fehlerbeschreibung bildet dann den Auf- 
takt zur eigentlichen Behebung des Fehlers, etwa durch Veränderung des Pro- 
grammcodes der Applikation in der gewünschten Weise. Damit wechselt die 
Arbeit dann auch den Standort. In Form eines genauer spezifizierten Fehlerbe- 
richts landet das Problem beim zuständigen Projektmanager in den Offshore- 
Entwicklungszentren. Dort kümmert sich dieser zusammen mit dem Offshore- 
Team um die entsprechende Veränderung des Programmcodes sowie die sich 
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daran anschließenden Testverfahren, um den neuen Programmcode auf seine 
Fehlerfreiheit und Eignung zu prüfen. 

Sodann wird der geänderte Programmcode an das Onsite-Team zurückgegeben. 
Dieses implementiert - meist nach einer erneuten kurzen Testphase in den Live- 
Systemen des Kunden - das Programm beim Kunden und schließt den Prozess 
damit ab. In der Realität laufen die Prozesse jedoch keinesfalls so linear ab, wie es 
in dieser Darstellung zum besseren Verständnis angenommen wurde, es kommt 
zu Rückkopplungsschleifen, wenn Spezifikationen z.B. unklar oder unvollständig 
sind, ebenso finden mehrere dieser Abläufe parallel statt. 


Der Ablauf eines Entwicklungsprojektes hingegen gestaltet sich etwas anders. Ent- 
wicklungsprojekte sind Projektgeschäft im engeren Sinne, d.h. sie sind einmalig? 
für eine bestimmte Zeit geplant und enden nach dieser Zeit. 

Den Auftakt eines Entwicklungsprojektes bildet der Wunsch eines Kunden 
nach einem bestimmten Programm oder einer sonstigen Applikation. Dieser 
Wunsch wird vom Onsite-Coordinator und seinem Team in einer ersten Phase 
des Projekts in Diskussion mit dem Kunden in ein Pflichtenheft für die Software 
transformiert. Das Pflichtenheft enthält im besten Fall eine vollständige und be- 
reits grob vorspezifizierte Liste aller vom Kunden gewünschten Funktionalitäten 
sowie die geforderten technischen Grundlagen der Applikation (Datenbanken, 
Programmiersprachen, etc.). Das Pflichtenheft bildet also ein erstes grobes Design 
der zu erstellenden Applikation. Zusammen mit dem Kunden wird ebenfalls eine 
erste Version des Projektplans erstellt. Dazu werden die zur Programmierung 
der Applikation nötigen Arbeitspakete identifiziert, die Zeitrahmen der Aufga- 
ben abgestimmt und sodann der benötigte Personalschlüssel festgelegt. Dieser 
vorläufige Projektplan wird vom Kunden abgesegnet und fungiert in der Fol- 
ge als Grundlage weiterer Verhandlungen mit dem Kunden, z.B. bei etwaigen 
Änderungswünschen. 

Der vorläufige Projektplan wird zur weiteren Bearbeitung an den im Offshore- 
Entwicklungszentrum für das Projekt zuständigen Projektleiter weitergereicht, 
der dort das Team zusammenstellt. Einer Phase des detaillierten Designs der 
Applikation folgt dann die Programmierungs- und Testphase, die beide dort 
erledigt werden. 

Wie bei Maintenance-Projekten auch, wird das Programm anschließend vom 
Onsite-Team beim Kunden übergeben, d.h. implementiert. Während der Entwick- 


> Dies gilt, sofern sie nicht mit einem Vertrag über anschließende Wartung gekoppelt sind, die 
dann häufig langfristige Zusammenarbeitsverhältnisse schaffen, aus denen weitere Entwicklungs- 
projekte folgen. 
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lungsphase ist das Onsite-Team mit der Aufnahme von sogen. „Change-Requests“ 
des Kunden befasst, also wechselnden Anforderungen des Kunden, die in die 
entstehende Applikation nachträglich integriert werden müssen. 


Ein wichtiger Unterschied zwischen Maintenance- und Entwicklungsprojekten 
ist zudem die meist höhere Komplexität des Arbeitsgegenstandes eines Entwick- 
lungsprojektes, die sich auch in der regionalen Zusammensetzung der Teams 
widerspiegelt. 

Grundsätzlich wird bei Service Tec versucht, ein Verhältnis von 30 zu 70 zwi- 
schen Onsite- und Offshore-Mitarbeitern des Delivery-Bereichs in den Projekten 
herzustellen. D.h. 30% der in einem Projekt beschäftigten Mitarbeiter sollten 
sich vor Ort beim Kunden befinden, 70% in den Entwicklungszentren Offshore’. 

Dabei handelt es sich jedoch mehr um einen Richtwert, als um klare Vorgaben. 
In der Realität sind große Unterschiede im konkreten Setup der Projektstruk- 
turen auffindbar. Dies zum einen, weil sich je nach gewünschter Leistung bzw. 
auch der Komplexität der Projekte ganz unterschiedliche Anforderungen an die 
Verteilung stellen. Bei sehr komplexen, beratungsintensiven Entwicklungsprojek- 
ten kann das Onsite-Team erheblich größer ausfallen, bei klaren, routinemäßigen 
Projekten jedoch auch wesentlich kleiner. So ist das Onsite-Team in Maintenance- 
Projekten gewöhnlich eher kleiner, teilweise - bei längerer Zusammenarbeit mit 
einem Kunden, wenn sich eine verlässliche Zusammenarbeit entwickelt hat - 
kann ganz auf einen Onsite-Teil verzichtet werden. 

Bei Entwicklungsprojekten ist der Anteil der Onsite-Mitarbeiter in der Regel et- 
was größer, wobei es sich keineswegs um ein konstantes Verhältnis handeln muss. 
So variieren die Teamgrößen auch im Projektverlauf. Ist der direkte Kontakt zum 
Kunden vor allem am Anfang und am Ende eines Projektes wichtig, so kann das 
Onsite-Team bei geringem Abstimmungsbedarf während der Bearbeitungsphase 
auch reduziert werden. Dies wird wiederum auch vom Abstimmungswunsch der 
Kunden beeinflusst, der in seiner Intensität zwischen den Kunden nach Aussagen 
der interviewten Gesprächspartner stark variiere. 

Wichtig bei dieser Arbeitsteilung ist, dass auch die Personen, die gegenwärtig 
Onsite beim Kunden arbeiten, in Indien wohnhaft bleiben und für die Dauer 
ihrer Aufgaben zum Kunden entsandt werden. Die im Sales- und Engagement- 
Bereich tätigen Personen sind hingegen in den Kundenregionen wohnhaft. In 


é Wie bereits erwähnt, unterhält ServiceTec mittlerweile auch Nearshore-Entwicklungszentren 
in anderen Niedriglohnregionen oder auch den USA. Dass dort jedoch der Delivery-Prozess 
schwerpunktmäßig verankert wird, ist sehr selten und geht in solchen Fällen auf besondere 
Umstände zurück, wie z.B. die klare Präferenz der Kunden für Nearshore-Projekte. 
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Deutschland handelt es sich dabei bislang oft um nach Deutschland gezogene 
Inder, jedoch liegt hier der Fokus (primär wegen benötigter deutscher Sprach- 
kenntnisse) auf der zunehmenden Rekrutierung von deutschen Beschäftigten für 
diese Bereiche. 

ServiceTecs globales Geschäftsmodel beruht also auf einer klaren, regional 
differenzierten Arbeitsteilung. An den unterschiedlichen Standorten (Onsite/Off- 
shore) sind unterschiedliche Arten von Tätigkeiten konzentriert. Dies ist durch- 
aus eine typische Struktur für Anbieter von Offshore-Outsourcing-Dienstleistun- 
gen. 


Ebenso typisch ist die enorme Prozessorientierung ServiceTecs, die in Kapitel 
2.1 bereits als besonderes Merkmal des „Global Delivery Models“ der indischen 
IT-Dienstleister benannt wurde. So sind eine ganze Palette standardisierter und 
international zertifizierter Prozessmodelle bei ServiceTec allgegenwartig: 


„Yes, I mean, these are all working standards, like CMM. Ithink CMM, 
everybody has it now. So you have CMM - CMMI, PCMM. So there is 
a whole bunch of the CMM stuff we have. Then you have Six Sigma, the 
European SPiCE system, then you have EFQM. There is a whole bunch of 
this.“ (SD6) 


ServiceTec ist demnach für eine ganze Reihe international anerkannter Prozess- 
modelle zertifiziert. Diese Prozessmodelle spielen bei ServiceTec eine vielfältige 
Rolle. 

Auf der einen Seite dienen sie als Qualitätssignal an die Kunden, die eine 
Implementierung solcher Prozessstandards durch ihren Auftragnehmer mitt- 
lerweile als entscheidende Voraussetzung für eine Zusammenarbeit ansehen. 
Das Outsourcing-Geschäft ist ein kundendominiertes. Da Kostengesichtspunk- 
te nach wie vor ein wesentlicher Gesichtspunkt bei der Wahl eines Offshore- 
Dienstleistungsanbieters sind, sind Kunden sehr an einer möglichst effektiven 
Durchführung der ausgelagerten Projekte interessiert. Dies führt einerseits zu 
einem starken Kostenwettbewerb zwischen den Anbietern von IT-Dienstleistun- 
gen, aber andererseits auch zu einem starken Engagement der Kunden bei der 
Planung und Durchführung der Projekte. So berichten viele Projektmanager von 
Service Tec, dass Kunden meist versuchten, sich sehr weit in die internen Prozesse 
bei ServiceTec einzumischen, und bei der Auftragsvergabe bereits sehr detail- 
lierte Angaben über die einzelnen Arbeitsschritte und den jeweils veranschlag- 
ten Arbeitseinsatz verlangten. Daher sind die ausgefeilten und allgegenwärtigen 
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Prozessbeschreibungen bei ServiceTec durchaus auch als Ergebnis des starken 
Kundendrucks zu interpretieren. 

Doch Prozessmodelle sind nicht nur Werbung und damit kundengetrieben, 
sondern sie bilden nach Angaben des höheren Managements auch die zentrale 
Grundlage für die global verteilten Arbeitsprozesse bei ServiceTec. Zu diesem 
Zweck werden jedoch nicht alle möglichen Prozessstandards parallel implemen- 
tiert. Vielmehr werden ausgewählte Prozesse zu einem firmeneigenen und leider 
auch streng vertraulichen Prozessmodell verknüpft: 


„So this is our quality standard, this is our process, this is our methodology 
and these are the components you see of Six Sigma, these are the com- 
ponents you see, so we have taken the best in pieces of all of them and put 
them in our ServiceTec quality system. But individually, we have certifi- 
cations for all of them, so, we are a Six Sigma company, we are a CMM 
company. [...] All this is there, but the process we follow is components 
of that fit together, which we call, we are not very creative in names, so 
calling it ServiceTec quality.“ (SD6) 


Dieses „ServiceTec Quality Process Model“ ist dabei als ein großer Rahmen zu 
verstehen, denn in dieses Prozessmodell gehen sowohl Ablauf- und Verfahrens- 
vorschriften für die im jeweiligen Projektschritt durchzuführenden Tätigkeiten, 
als auch Angaben bzgl. der in den einzelnen Arbeitsschritten zu erstellenden Do- 
kumente bzw. sonstigen Artefakte ein. Dieses Prozessmodell ist die Grundlage 
des Projektmanagements für alle innerhalb von Service Tec ablaufenden Projekte. 
Das Ziel, das damit verfolgt wird, ist eine Standardisierung und Formalisierung 
der Arbeitsprozesse. In diesem Zusammenhang wird bei Service Tec auch ganz 
offen und offensiv der Begriff der IT-Industrialisierung zur Beschreibung dieses 
Vorgehens gebraucht: 


„See, we want to remove this big exotic thing of software from people’s 
heads. You know, that you have to have hundred people sitting in your 
office to design a software you want for doing analysis, because it’s all 
about feeling and German software is different [...]. It’s not like that. It’s 
like making a car! You figure out a process, you figure out a team and 
just put it. [...] Ithink that’s the biggest thing with Indian companies at 
the time, not only ServiceTec. They have industrialized it. The word is 
“Industrialisierung’ of the software, they have taken off that entire charm 
of a bunch of people doing something creative and making very ... funky 
systems. [...] They just say ‘look, insurance is insurance. There is a claim, 
there is an insurer, there is an act one. Yeah ... German insurance is a little 
bit different, we plug it in later. Let’s just do it’“ (SD6) 
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Die Abgrenzung von IT-Arbeit als kreativer und kunsthandwerklicher Tätigkeit 
bildet einen ganz wesentlichen Aspekt des Selbstverständnisses und auch der Ge- 
schäftsstrategie von ServiceTec, wie sich im folgenden Zitat desselben Managers 
deutlich zeigt: 


„A lot of this exoticness about software - I don’t know - you need these big 
shot consultants who come in and show you the future about... - and that’s 
why Germany is loosing out. It needs to figure out that ‘look, software is 
no big deal’. In Germany, if you go to any company, probably here it’s a bit 
different. You talk to a [Name eines deutschen IT-Dienstleisters - PF] guy 
tomorrow and say ‘I want to meet five or six of your consultants’. You'll 
see them, you'll see them all ... doctors and everything, they will be there 
with a suit and a tie. And they will talk strategy, they will talk vision of 
building...“ 

F: We wouldn’t meet one here? 

„I doubt it. If you meet them, they are just acting to impress you. [lacht]“ 
(SG6) 


Die - offen formulierte - Absicht hinter dieser stark formalisierten und struk- 
turierten Form des Projektmanagements bei ServiceTec ist, den Projektverlauf 
möglichst unabhängig von den im Projekt beschäftigten Personen zu machen. 
Dies ist in zweierlei Hinsicht zu verstehen: 

Einerseits bilden die strikten Prozesse die Grundlage der Zusammenarbeit der 
Beschäftigten an den unterschiedlichen Standorten. Der Projektmanager eines 
Onsite-Teams beschreibt die Funktion von Prozessbeschreibungen in der direkten 
Kooperation zum Offshore-Team folgendermaßen: 


„There is the guys, the people focus on the job, which is on the hand. [...] 
See, if they have to get this done, it doesn’t matter, who that person is, as 
long as both of them understand and know, what needs to be done to get 
the job done.“ (SD4) 


So gefasst, schaffen die standardisierten und formalisierten Verfahrensvorschrif- 
ten, die in dem Prozessmodell festgeschrieben sind, also die Möglichkeit, Per- 
sonen eng kooperieren zu lassen, die häufig nicht die Möglichkeit haben, sich 
persönlich kennenzulernen, weil sie sich in räumlich weit entfernten Standorten 
befinden. 

Andererseits wird aber auch ganz konkret Unabhängigkeit von einzelnen Be- 
schäftigten angestrebt. Die Prozessbeschreibungen sollen den Projektablauf an 
diese standardisierten Vorgaben und auch die jeweils verantwortlichen Beschäf- 
tigten an ein bestimmtes Vorgehen binden. So soll explizit vermieden werden, 
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dass einzelne Beschäftigte einem Projekt „eine persönliche Note“ geben und 
damit eine schwer ersetzbare Position im Projekt einnehmen können. Gerade 
vor dem Hintergrund der hohen Fluktuationsraten am indischen Standort wird 
dieses Motiv plausibel, sollen die häufigen Wechsel in den Projektteams nicht zu 
Problemen im Projektverlauf führen. Von daher sind diese Prozesse so gestaltet, 
dass, wie sich eine Projektmitarbeiterin in Indien ausdrückt, 


„[...] the project should not be dependent on a particular person at any 
point. [...] Supposing this person leaves the company, ServiceTec, or leaves 
this project, then there is a major problem in the project, like, there is a 
major lack of knowledge there. We make sure, that never happens.“ (SI13) 


Das geflügelte Wort für dieses Managementziel ist die (von Beschäftigten unter- 
schiedlicher Ebenen bei Service Tec oft mantra-artig wiederholte) Aussage, dass 
Projekte stets „process-depending and not people-depending“ sein sollten. 


ServiceTec stellt in Bezug auf die in dieser Studie verfolgte Fragestellung da- 
her einen Fall dar, in dem die Industrialisierung der Arbeitsprozesse besonders 
deutlich zu Tage tritt. Wie in den nächsten Abschnitten zur konkreten Kontroll- 
strategie, die Service Tec in seinen Offshore-Entwicklungszentren verfolgt, noch 
gezeigt werden wird, führt diese intendierte, weitreichende Industrialisierung 
der Arbeitsprozesse bei Service Tec auch zu stark repressiven Formen der Ar- 
beitsprozesskontrolle. Die folgende Analyse der Kontrollstrategie Service Tecs 
in ihren Offshore-Entwicklungszentren anhand der vier Aktivitätsfelder wird 
zeigen, wie die strategischen Entscheidungen Service TTecs dabei auf der einen Seite 
vom skizzierten Geschäftsmodell und auf der anderen Seite von der Situation auf 
dem indischen Arbeitsmarkt geprägt sind. 


5.3 „Jack of all trades and master of none“ - 
Betriebliche Kontrollstrategien bei ServiceTec im 
Entwicklungszentrum in Bangalore 


Gemäß des Geschäftsmodells und der internationalen Arbeitsteilung von Service- 
Tec befinden sich vor allem die Teams des Delivery-Bereiches in den Offshore- 
Entwicklungszentren. Zwar gibt es auch zunehmend Bemühungen, Bereiche, 
die dem Sales und Engagement-Bereich unterstützend zuarbeiten, Offshore zu 
lokalisieren, jedoch sind diese Bereiche noch sehr klein und nur vereinzelt anzu- 
treffen. Von daher konzentriert sich diese Untersuchung ganz auf die Analyse 
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der Kontrollstrategien im Delivery-Bereich. Der Aufbau der Darstellung folgt 
der in Kapitel 4.3 vorgenommenen Operationalisierung und Dimensionierung 
des in dieser Studie verwandten Kontrollbegriffs. 


5.3.1 Aufgabenorganisation 
Aufgabenschwerpunkt des indischen Entwicklungszentrums 


Zur Beschreibung der Arbeitsabläufe in der Softwareentwicklung wird gewöhn- 
lich auf den sogen. „Software-Lifecycle“ rekurriert. Demnach lassen sich bei der 
Erstellung von Software nach dem sogen. ,,Wasserfallmodell*’ folgende Phasen 
der „Produktion“ unterscheiden (vgl. Abbildung 5.1): Einer Phase der Problemi- 
dentifizierung und entsprechender Analyse folgt in der Regel eine Phase, in der 
ein technisches Design der zu entwickelnden Software entworfen wird. Anschlie- 
Bend folgt der Prozess der eigentlichen Softwareentwicklung, also die Phase des 
Kodierens und Testens der Software. Dieser mündet in die Implementierung der 
Software. Daran schließt sich evtl. eine Phase der Wartung an. 

Die bei ServiceTec an die Offshore-Entwicklungszentren verlagerten Tätigkeiten 
im IT-Dienstleistungsbereich lassen sich als Tätigkeiten am unteren Ende des 
Software-Lifecycles beschreiben. Die frühen Phasen, wie die Identifizierung 
der Anforderungen an die Software, setzen intensive Kommunikation mit den 
Kunden voraus, weshalb hier räumliche Nähe wichtig ist. 


„Z.B. Anforderungsspezifikation - wenn man mit dem Kunden direkt 
arbeiten muss, um ihn zu fragen: Was sind die Spezifikationen? Dafür 
braucht man eher Onsite. Telefonisch oder per Mail, Offshore ist das sehr 
schwierig, hier mit acht Leuten vom Kunden zu sprechen jeden Tag und 
dann die Spezifikationen zu verfeinern. Dafür brauchen wir hier Onsite.“ 
(SD7) 


7 In der Regel wird zwischen linear und iterativ ablaufenden Prozessen der Softwareentwicklung 
unterschieden: Lineare Modelle sind z.B. das bekannte Wasserfallmodell, iterative Modelle wie 
z.B. Extreme Programming sind dagegen eine relativ neue Erscheinung. Entgegen der linearen 
Modelle, die auf eine klare, zeitlich lineare Abfolge der Entwicklungsschritte aufbauen, steht 
bei den iterativen oder auch agilen Prozessen eher eine spiralförmige Entwicklung mit kurzen 
Feedback- und Respezifizierungsschleifen im Fokus. Diese Prozesse setzen aber erhöhte Kommu- 
nikation mit evtl. Kunden oder Auftraggebern voraus, weshalb sich die Ansicht hartnäckig hält, 
dass iterative Methoden der Softwareentwicklung bei Offshoring-Projekten nicht von Vorteil 
seien. Unabhängig davon, ob es generell möglich ist oder nicht, stellt das Wasserfall-Modell bei 
ServiceTec die präferierte Form der Softwareentwicklung dar. 
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Verification 


Maintenance 


Abbildung 5.1: Wasserfall-Modell der Softwareentwicklung (Quelle: 
http://en-wikipedia.org/wiki/File:Waterfall_model.png, abge- 
rufen am 22.02.2010) 


Ab der Phase des Designs erfolgt in der Regel in Entwicklungsprojekten die 
Verlagerung. So werden die Offshore-Entwicklungszentren haufig zum detaillier- 
teren Design, der folgenden Programmierung und des Testens der Entwicklung 
genutzt. Die Phase der Implementierung beim Auftraggeber setzt dann wieder 
die räumliche Nähe zum Kunden voraus, da auf deren Systeme zugegriffen wer- 
den muss und meist zusätzliches Personal beim Kunden geschult, bzw. angeleitet 
werden muss. 

Die abschließende Phase des Maintenance wiederum ist Gegenstand der Main- 
tenanceprojekte, setzt allerdings voraus, dass es sich um zu wartende Systeme 
oder Applikationen handelt, auf die auch von außen gut zugegriffen werden kann 
(vgl. Heeks 1995, S.369ff.; Aspray, Mayadas und Vardi 2006, S.54ff.; Dossani 
und Kenney 2004, S.386f.). Diese Verteilung ist natiirlich nicht statisch, sondern 
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stellt sich in Abhängigkeit von der konkreten Art des Projektes leicht unter- 
schiedlich dar (siehe die Beschreibung der Arbeitsteilung in Maintenance- und 
Entwicklungsprojekten in Kapitel 5.2). Dennoch bleibt festzuhalten, dass die 
Tätigkeiten, die Offshore erledigt werden, im wesentlichen Programmier-, Test- 
und Wartungsarbeiten sind, während die kommunikationsintensiven Tätigkeiten 
von Anforderungsanalyse und Design vor Ort beim Kunden erbracht werden. 


„Der Fokus von den Onsite Teams liegt darauf, die Interaktion mit dem 
Kunden zu betreiben und alle Sachen, die mit dem Kunden direkt bespro- 
chen werden müssen, auch durchzudiskutieren, und außerdem liegt sie ein 
bisschen auf der sprachlichen Komponente. Das heißt, wenn ich Dokumen- 
tationen habe, die auf Deutsch erstellt werden müssen - die würde ich dann 
von den Leuten hier vor Ort machen lassen, weil es dann auch in engerer 
Abstimmung mit dem Kunden alles erfolgen kann.“ (SD3) 


Mit dieser Arbeitsteilung zwischen Onsite- und Offshore-Teams des Delivery 
Bereiches bei Service Tec geht eine Asymmetrie bzgl. planender und ausführender 
Tätigkeiten einher. Wesentliche Entscheidungen bzgl. des Projektverlaufs und 
auch erste richtungsweisende Entscheidungen, z.B. bzgl. des Designs der zu 
entwickelnden Software in einem Entwicklungsprojekt, werden onsite von den 
sich dort befindlichen Personen in Kooperation mit dem Kunden getroffen. Die 
auf die Offshore-Entwicklungszentren entfallenden Tätigkeiten sind demnach 
eher ausführender Art. Dies beeinflusst auch die Komplexität der Arbeitsaufgaben 
wesentlich. So lässt sich bei ServiceTec konstatieren, dass sich die komplexeren 
Tätigkeiten bei den Teams onsite finden, was sich auch daran zeigt, dass Service Tec 
ausschließlich erfahrene Beschäftigte vor Ort beim Kunden einsetzt: 


„Mindestens ein Jahr Projekterfahrung muss man haben, um vor Ort zu 
kommen. Das haben wir intern, projektintern die Regelung gemacht. ... 
Weil die Komplexität war einfach zu hoch, um das Risiko einzugehen. Wenn 
wir unerfahrene Entwickler hier vor Ort bringen würden, und wenn der 
Kunde dann mit denen unterhaltet und dann die Erfahrung sammelt: ’Aha, 
in wessen Händen ist unsere Software eigentlich?’. Um das zu vermeiden.“ 


(SD8) 


Dabei ist die Hürde mit einem Jahr Betriebszugehörigkeit in diesem Projekt 
noch niedrig, in anderen Projekten sind die Anforderungen an die Erfahrung der 
Beschäftigten wesentlich höher: 


„Wir haben Software Engineers ... fast keinen. Weil die haben 3 bis 4 Jahre 
Erfahrung. Wir haben nur Programmer Analyst. Und dann wir haben 
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Project Managers. Und dann auf höhere Ebenen dann Project Managers - 
Senior Project Manager.“ (SD7) 


Nach Aussage dieses Managers werden Personen auf dem Einstiegsniveau (Softwa- 
reentwickler) von ServiceTec also so gut wie gar nicht onsite eingesetzt. Folglich 
finden sich fast ausschließlich Personen beim Kunden, die mindestens die zweite 
Hierarchiestufe erreicht und bereits 3-4 Jahre Erfahrung innerhalb von ServiceTec 
gesammelt haben. 

Erfahrung bemisst sich aber nicht nur in der reinen Dauer der Zugehörigkeit 
zum Unternehmen und der Arbeit in Projekten von ServiceTec. Vielmehr liegen 
auch die Qualifikationsanforderungen für Beschäftigte der Onsite-Teams höher. 
Personen, die vor Ort beim Kunden arbeiten wollen, müssen vorher bestimmte - 
je nach Projekterfordernissen verschiedene - interne Zertifizierungen erwerben. 
Dabei müssen sie technische, aber vor allem auch branchenspezifische Kenntnisse 
beweisen, die für die Mitarbeiter Onsite von weitaus größerer Wichtigkeit sind 
als für die Beschäftigten Offshore, da man Onsite ganz unmittelbar mit dem 
Kunden bei der Spezifikation der Leistungen zusammenarbeitet: 


„Versicherungskenntnisse zum Beispiel. In diesem Fall haben wir schon 
versucht, aber die meisten hatten es sowieso nicht. Und wir hatten dann 
intern angefangen, Versicherungszertifikation zu machen, abzuschließen, 
und ... das ist jetzt mittlerweile ein Kriterium geworden.“ (SD8) 


Zudem erfordert eine Onsite-Beschäftigung nach Ansicht des im folgenden zitier- 
ten Vertreters des höheren Managements Führungserfahrung: 


„Und ich will eigentlich auch hier Leute haben, die ’ne robuste Berufserfah- 
rung haben. Weil ob die Leute jetzt ... ’ne Programmer Analyst Rolle haben 
in diesem Projekt vielleicht oder nicht - sie werden aber dadurch, dass sie in 
dieser Kundensituation stehen, auf jeden Fall Führungserfahrung brauchen. 
Und deswegen will ich da eigentlich Projektmanager sitzen haben.“ (SD3) 


Aufgrund dieser (für das „Global Delivery Model“ Service Tecs spezifischen) 
Form der Arbeitsteilung kommt es also bereits zu Ungleichgewichten in Be- 
zug auf die am jeweiligen Standort zu bearbeitenden Aufgaben. Den Offshore- 
Entwicklungszentren fallen in diesem Geschäftsmodell dabei eher die ausführen- 
den und damit auch weniger komplexen Arbeitsaufgaben zu. 

Ergibt sich diese Asymmetrie bereits aus dem für IT-Dienstleister typischen 
Kundenkontakt und der damit zusammenhängenden Form der globalen Ar- 
beitsteilung, so wird in den Offshore-Entwicklungszentren ServiceTecs versucht, 
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die Komplexität der vom einzelnen Entwickler zu bearbeitenden Arbeitsauf- 
gaben darüber hinaus noch weiter zu reduzieren. Dies beginnt schon bei der 
organisatorischen Struktur der Offshore-Teams. 


Teamstruktur und Tätigkeitsprofile 


Ein Offshore-Projektteam besteht gewöhnlich aus mehreren sogen. „Modulen“ 
mit bis zu 4 Entwicklern und einem Modulleiter als fachlichem Vorgesetzten. 
Jedes Modul ist für einen bestimmten entsprechend klar abgegrenzten und spe- 
zifizierten Teil der zu erbringenden Leistung (entweder der Entwicklung oder 
der Wartung) verantwortlich. Die verschiedenen Module, die in ihrer Zahl je 
nach Projektart und -größe variieren, werden von einem Gesamtprojektleiter 
koordiniert und kontrolliert. 


„A typical project would be headed by a project manager. And then the 
project would have different modules. Each module would be headed by a 
module leader. [...] And each of these modules would have a set of software 
engineers. That’s a typical structure of a project.“ (SI7) 


Die Projekte sind zudem auch räumlich modular strukturiert. Normalerweise 
sitzen der Modulleiter und die seinem Modul zugeordneten Entwickler in einem 
eigenen sogen. „Cubicle-Komplex“ zusammen. Ein solcher Komplex besteht 
aus jeweils zwei aneinander liegenden mit Trennwänden seitlich abgetrennten 
Wiirfeln. In dem einem Würfel befinden sich die Arbeitsplätze für das Modul- 
Team, im anderen ein Arbeitsplatz für den Module-Lead. Die Gesamtheit der 
Cubicle-Komplexe - das gesamte Projektteam - befindet sich meist in unmittelba- 
rer Nachbarschaft zueinander. Der Projektmanager hat sein Büro in der Nähe 
der Cubicles, allerdings nicht in diesen selbst. Die räumliche Organisation der 
Projektteams unterstützt in seiner Form die Kontroll- und Kommunikationser- 
fordernisse der Arbeitsprozesse, wie sich an späterer Stelle noch genauer zeigen 
wird. Zunächst aber führt diese Strukturierung der Teams dazu, dass die einzel- 
nen Entwickler in der Regel ausschließlich an kleinen Teilen der Applikation 
arbeiten und Fragen des Zusammenhangs von einzelnen Teilen und Gesamtappli- 
kation nicht auf der Ebene der Entwickler bearbeitet werden. Innerhalb der 
Projektteams findet sich daher eine starke Arbeitsteilung, die dazu führt, dass die 
Entwickler klar spezifizierte, extrem kurztaktig zugeschnittene und individuell 
zugewiesene Arbeitsaufgaben erhalten. 


Um die teaminterne Arbeitsteilung zu verstehen, sollen kurz die an der Pro- 
jektbearbeitung beteiligten Rollen und ihre Tätigkeitsprofile näher beschrieben 
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werden’. Ein Projektmanager erläutert die einzelnen, den Tätigkeitsprofilen 
hinterlegten Funktionen folgendermaßen: 


„If you look at the team primarily here, it would be the IT-team, so the 
general structure of a project would be: you’ll have a Project Manager 
and then you have Programmer Analysts and Software Engineers. But the 
primary responsibility of executing a project over time would be for the 
Project Manager. And the project might be divided into different modules 
and different areas, which would be owned by a Programmer Analyst. And 
then you'll have a Software Engineer executing it. This Programmer Ana- 
lyst would be responsible partly for the coding part as well and doing report 
reviews and Project Manager might have to involve themselves in other 
reviews like design reviews and requirement specification reviews etc. as 
well. But the Project Manager should analyze all the resource requirements, 
your project acquisition part, the critical part and the Project Manager also 
has to do kind of milestone-reporting analyses and to see, where the project 
is going and do a monitoring and control for the project.“ (SI17) 


Die Funktion des Projektmanagers besteht somit bei ServiceTec in erster Linie 
in der Planung, Koordination und Kontrolle des Gesamtprojektes. Dazu gehört 
auch das detaillierte technische Design der zu erbringenden Leistung und die 
Erstellung des Projektplans, Aufgaben, für die der Projektmanager meist mit 
den jeweiligen Modulleitern sowie der Technologieabteilung von Service Tec? 
eng kooperiert und durch das höhere Management bei Bedarf unterstützt bzw. 
beaufsichtigt wird. Die planenden Tätigkeiten konzentrieren sich also auf dieser 
Ebene, und strategische Entscheidungen hinsichtlich des Projektablaufes wer- 
den ebenfalls vom Projektmanager getroffen. Zudem ist der Projektmanager 
gegenüber dem höheren Management für die Ausführung des Gesamtprojek- 
tes verantwortlich. Der Projektmanager steht dazu in ständigem Kontakt mit 
den Modulleitern und kontrolliert den Status, die Kosten und die Qualität der 
geleisteten Arbeit. In die konkrete Durchführung der Projektarbeiten, wie der 
Programmierung, wird der Projektmanager hingegen nur einbezogen, wenn es 
Probleme gibt. Ansonsten ist die Aufsicht über die konkrete Arbeit der Entwick- 
ler Sache des Modulleiters. Allerdings führt der Projektmanager regelmäßige 


$ Die Fokussierung auf die an der Bearbeitung beteiligten Rollen schließt die nähere Spezifizierung 
der unterschiedlichen Rollen des höheren Managements aus. 

? Die Technologieabteilung ist eine spezielle Einrichtung innerhalb ServiceTecs. In dieser arbeiten 
Personen, die sich gezielt für eine technische Karriere innerhalb ServiceTecs entschieden haben 
und die die verschiedenen Projekte in technischer Hinsicht als Technologie-Experten beraten und 
unterstützen. Die technischen Teams sind daher meist lediglich am Anfang der Projektlaufzeit 
involviert, wenn das genaue technische Design der zu erbringenden Lösung spezifiziert wird. 
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Design- und Fortschrittskontrollen durch und kontrolliert damit die Arbeit der 
Modulleiter und die in den Modulen geleisteten Arbeiten. Der Arbeitstag der 
Projektmanager ist dementsprechend auch zum absoluten Großteil von Meetings 
sowie Planungs- und Koordinierungsaufgaben geprägt. Einzelarbeit hingegen 
findet nach Angaben der interviewten Projektmanager nur selten statt. 

Die nächste Rolle, die des Modulleiters - häufig auch als Programmanalyst 
bezeichnet - ist durch eine gewisse Zwischenstellung zwischen Management und 
Projektausführung gekennzeichnet. Die Modulleiter tragen die „bottom line 
responsibility for the deliverables“ (SI14), wie es ein Modulleiter von sich selbst 
sagt. So fällt die Sicherstellung der Programmierarbeiten in die Zuständigkeit 
der Modulleiter. Ein Modul besitzt i.d.R. ein klar umrissenes Themengebiet, 
meist ist es ein Teilbereich einer zu entwickelnden oder zu wartenden Applika- 
tion, z.B. eine Teilfunktion oder ein Unterprogramm. Für die Ausführung der 
Arbeiten, die diesem Modul zugerechnet werden, ist der jeweilige Modulleiter 
dem Projektmanager gegenüber verantwortlich. Der Modulleiter leitet dabei die 
Software-Entwickler in seinem Modul fachlich an, d.h. der Modulleiter ist stets 
die erste Anlaufstelle für die Entwickler bei Problemen mit ihren Arbeitsaufga- 
ben. Der Modulleiter ist jedoch auch selbst noch in die ausführenden Tätigkeiten 
einbezogen, indem er einerseits selber Teilarbeiten des Moduls verrichtet und 
andererseits die Arbeiten der Softwareentwickler eng kontrolliert, d.h. sogen. 
„Code-Reviews“, das sind persönliche Kontrollen des von den Entwicklern ge- 
schriebenen Programmcodes, durchführt. 

Darüber hinaus hat der jeweilige Modulleiter jedoch z.T. auch Projektma- 
nagementfunktionen. So obliegt ihm z.B. häufig die konkrete Zuweisung der 
Arbeitsaufgaben an die Softwareentwickler, wie ein Projektmanager aus seinem 
Projekt berichtet: 


„So, in our case it was the module leads, who were doing the daily as- 
signment, because we found it more productive, rather than the project 
manager doing it, we decentralized it to different modules. So if there is 
a production support request!°, there is a bunch of production support 
requests, so the module lead is in a better position to know, that, who is 
free, who is not free, who has to be assigned, who has knowledge in which 
subject area and all those things. And that module lead takes care of the 
assignment of only that particular bug fix module. The next module lead 
has the responsibility for his one module and finally the project manager 


1 Ein „production support request“ ist ein Arbeitsauftrag in einem Wartungsprojekt, bei dem der 
Kunde einen Fehler meldet und damit einen Arbeitsablauf zur Behebung des Fehlers einleitet. 
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normally reviews that once in a while, say once in a week or once in a 


fortnight.“ (SI3) 


Ein typisches Vorgehen besteht daher in den meisten Modulen darin, dass die 
Entwickler ihre Arbeitspakete vom jeweiligen Modulleiter zugewiesen bekom- 
men und dieser auch die folgende Abarbeitung persönlich begleitet, anleitet und 
kontrolliert. Ebenso nehmen die Modulleiter an der konkreten Planung des Pro- 
jektverlaufes in Zusammenarbeit mit dem verantwortlichen Projektmanager teil, 
helfen teilweise beim technischen Design und der Zeitschätzung der definierten 
Arbeitsaufgaben. 

Wie weit die Modulleiter jeweils in das Management des Projekts involviert 
sind, hängt dabei vom persönlichen Managementstil des Projektmanagers ab, wie 
ein Projektmanager verrät: 


„The project manager has the responsibility and it’s up to him - the way he 
runs his project. So, there are project managers, who have a higher degree 
of transparency and do counsel with their module leads - there are project 
managers, who don’t have a higher level of transparency, when it comes to 
making decisions.“ (SI3) 


So bestanden auch in den im Rahmen dieser Studie untersuchten Projekten durch- 
aus Unterschiede in dem Grad, zu dem Modulleiter in Managementaufgaben 
involviert wurden. 

Aufgrund dieser Zwischenstellung ist der Arbeitstag eines Modulleiters auch 
recht gleichmäßig zwischen Einzelarbeit und Koordinationsaufgaben aufgeteilt, 
ca. 3-4 Stunden des Arbeitstages entfielen nach Aussagen der Modulleiter auf 
Einzelarbeit, also auf eigenes Codieren oder Kontrollieren der Arbeiten der 
Entwickler, der Rest bestehe in Koordinationsaufgaben oder Meetings. 

Das Tätigkeitsprofil der Entwickler (Software-Engineers) schließlich markiert 
die Einstiegsebene bei ServiceTec. Es beinhaltet im wesentlichen die konkrete 
Ausführung der Projektarbeiten. Die Arbeitsinhalte wechseln zwar je nach Pro- 
jektart und der Phase, in der das Projekt sich jeweils befindet (Programmierung 
oder Testing bspw.), doch stets beinhaltet die Rolle der Software-Entwickler 
einen eindeutigen Fokus auf Technologie: 


„No, so for example, what we have clearly articulated is that for software 
engineer kind of profiles, the focus is on technology. So the first three to 
five years we believe, the person has to understand technology very well, 
because that’s what drives ourselves and that’s what we need to have as basic 
forming blocks. After that, a person can start focusing more on the domain. 
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So, I mean, first three years it’s purely technology, although there are some 
domain competencies and we try to build regional units of persons to send. 
But that’s not the primary responsibility. It’s technology. As you keep 
moving senior the focus moves from technology to domain. So initially 
you'll see a lot of people being moved from one unit to another, based on 
the way that technology requirements suit the person. So this is not really 
the domain, which impacts to such large an extent.“ (SI15) 


Die ersten Jahre im Unternehmen sind die Entwickler also primar mit dem 
Erlernen und der Erweiterung ihrer technischen Kompetenzen und Erfahrung 
beschäftigt. Erst nach und nach und mit zunehmender Intensität wird versucht, 
die Entwickler auch auf bestimmte Geschäftsfelder („domains“) und Herkunfts- 
länder („regions“) ihrer Kunden zu spezialisieren. Die letzte Bemerkung des 
zitierten Managers deutet bereits an, dass die Rolle des Software-Entwicklers bei 
ServiceTec dadurch eine besonders flexible ist. So werden Software-Entwickler 
je nach Projektbedürfnissen zwischen verschiedenen Projekten hin und her 
geschoben. Auf diese Weise reagiert ServiceTec flexibel auf im Projektverlauf 
unterschiedliche Personalbedarfe eines Projektes. Werden zu einer bestimmten 
Zeit viele Beschäftigte gebraucht, z.B. in intensiven Testphasen, so können schnell 
Beschäftigte anderer Abteilungen und Projektteams ausgeliehen werden. Wenn 
in einer anderen Phase der Personalbedarf hingegen sinkt, werden Beschäftigte 
aus den Projektteams freigesetzt und befinden sich anschließend „auf der Bank“, 
wie es bei ServiceTec heisst. Wer „auf der Bank“ sitzt, ist keinem konkreten Pro- 
jekt zugeordnet und widmet sich weiteren Trainingsmaßnahmen, bis ein neues 
Projekt Bedarf anmeldet und die Person in diesem Projekt zu arbeiten anfängt. 
Die „Bank“ stellt demnach einen flexiblen internen Markt für Arbeitskräfte dar, 
auf den von den unterschiedlichen Projekten zugegriffen werden kann. 

Auf der Ebene der Entwickler würde eine fachliche oder länderspezifische 
Spezialisierung das stete Ersetzen und Wechseln der Entwickler zwischen den 
Projektteams eher erschweren als erleichtern, wenn Entwickler nicht frei in 
möglichst vielen Bereichen des Unternehmens eingesetzt werden könnten. So 
liegt der Fokus für die Entwickler zunächst rein auf der technologischen Ebene 
und auch innerhalb der technologischen Ausbildung wird versucht, technische 
Spezialisierung möglichst zu vermeiden. 

Daher bekommen die Entwickler bei Service Tec auch primär relativ gleichför- 
mige Arbeitsaufgaben zugeteilt, die nicht nach individuellen Kompetenzen oder 
Vorerfahrungen variieren. 
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„Basically all the juniors are doing almost similar kind of work. So there is 
no selection as such.“ (SI14) 


Wer also eine Zeitlang an einem Java-Projekt gearbeitet hat, wird nicht zwangs- 
läufig beim nächsten Mal wieder in einem Java-Projekt arbeiten, sondern wahr- 
scheinlich eher in einem Projekt, das C++ oder eine andere Programmiersprache 
einsetzt. 

Die Arbeit der Software-Entwickler ist vorwiegend Einzelarbeit. Zwar ko- 
operieren die Software-Entwickler bei Problemen oder Unklarheiten direkt 
miteinander, was durch die Arbeitssituation innerhalb desselben Cubicles auch 
unterstützt wird, aber in der Regel besteht der Tag aus Arbeit an individuell 
zugewiesenen Aufgaben: 


„At the junior level the whole day is almost like working on something 
that is allocated to them.“ (SI14) 


Definition und Zuweisung von Arbeitsaufgaben 


Wie sich aus der Schilderung von Teamstruktur und Tatigkeitsprofilen bereits 
erahnen lässt, verfolgt ServiceTec in seinen Arbeitsablaufen einen sehr klaren 
„top-down“ Ansatz. Die notwendigen Tätigkeiten werden über die genannten 
Hierarchiestufen des Projektmanagers, der Modulleiter bis hin zu den Software- 
Entwicklern immer weiter heruntergebrochen. Planende Tätigkeiten nehmen in 
diesem Prozess von Stufe zu Stufe kontinuierlich ab. Am Ende - auf der Ebene der 
Softwareentwickler - stehen kleinteilige, stark vorspezifizierte Arbeitsaufgaben 
für die Entwickler, die wenig kreative Anforderungen beinhalten. 

Dazu muss gesagt werden, dass ServiceTec im IT-Dienstleistungsbereich sehr 
unterschiedliche Projekte durchführt, deren technische Komplexität stark vari- 
iert. So finden sich bei Projekten, die auf die Entwicklung einer individuellen 
Softwarelösung zielen, wesentlich komplexere Anforderungen, als bei der Ent- 
wicklung einer kleineren Erweiterung für ein bereits bestehendes Produkt oder 
der Wartung einer sich in Betrieb befindlichen Applikation. Von daher sind 
die Anstrengungen, die Service Tec unternehmen muss, um die vom Kunden 
kommenden Anforderungen in kurztaktige Arbeitspakete für die Entwickler 
umzusetzen, unterschiedlich stark. So verlangt z.B. die Weitergabe von War- 
tungsaufträgen an die Entwickler weniger Aufwand, da Fehlermeldungen häufig 
bereits in ausreichend spezifizierter Form von den Beschäftigten des Kunden- 
unternehmens kommuniziert werden können. In diesem Fall reduziert sich die 
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Aufgabe des Verteilens der Arbeitsaufgaben daher mehr oder weniger auf eine 
reine Weitergabe der Arbeitsaufgaben!". 

Im Großteil der von ServiceTec durchgeführten Projekte kommen die Arbeits- 
aufgaben jedoch lediglich grob vorspezifiziert vom Kunden bzw. dem Onsite 
Team. Wie bereits beschrieben, obliegt den Onsite-Projektteams die Aufgabe, in 
Kooperation mit dem Kunden ein erstes grobes Design der verlangten Leistung 
herzustellen. Ein solches Design ist bereits mit ersten Aufwandsschätzungen, d.h. 
einer groben Zeitplanung und einer Schätzung der benötigen Teamstärke des 
Projektteams, verbunden. 

In diesen Fällen werden die Vorgaben anschließend vom zuständigen Projekt- 
manager des Offshore-Teams in Zusammenarbeit mit technischen Beratern, den 
Module-Leads und je nach Komplexität des Projektes auch von Angehörigen 
des höheren Managements in ein sehr detailliertes, technisches Design der zu 
erbringenden Lösung und einen feingliederigen Projektplan umgesetzt. 

Dieses Vorgehen geht nicht nur auf strategische Überlegungen und Entschei- 
dungen Service Tecs zurück, sondern es wird auch unterstützt von der Vorsicht 
und dem Kontrollbedürfnis der Kunden. Nach Aussagen von Projektmanagern 
haben die Kunden von sich aus ein sehr großes Interesse an möglichst detail- 
lierten Projektplänen mit kleinschrittigen Rückmeldeschleifen. Nach Angaben 
von Kundenbetreuern bei ServiceTec erhofften sich die Kunden dadurch die 
Möglichkeit, eventuellen Fehlentwicklungen im Projektverlauf früh entgegen- 
wirken zu können. Der Offshore erstellte feingliederige Projektplan ist daher 
in den meisten Projekten auch vom Kunden abzuzeichnen, bevor das Projekt 
anschließend in seine Bearbeitungsphase übergeht. Es sind also keinesfalls nur 
strategische Entscheidungen ServiceTecs, die für die Form der Arbeitsabläufe 
ausschlaggebend sind. Gerade an diesem Punkt wird der Einfluss des Kunden 
und damit auch die Rolle des Geschäftsmodells - für das der Bezug auf externe 
Kunden als Anbieter von Offshore-Outsourcing-Dienstleistungen konstitutiv ist 
- für die Form der Aufgabenorganisation bei Service Tec sehr deutlich. 


Das Herunterbrechen der Arbeitsaufgaben beruht ganz wesentlich auf den in 
den indischen Entwicklungszentren von ServiceTec allgegenwärtigen Prozess- 
modellen und -vorgaben. Die Prozessorientierung ist daher bei ServiceTec auch 


11 So wird diese Allokation von Arbeitsaufgaben in den im Rahmen dieser Studie untersuchten 
Wartungsprojekten teilweise auch über rein technische Fehlermeldungssysteme erledigt, in die 
der Kunde Fehlermeldungen eingibt und diese anschließend direkt an den für den fehlerhaften 
Programmteil zuständigen Modulleiter in den Offshore-Entwicklungszentren geschickt werden, 
der dann die teaminterne Verteilung übernimmt. 
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das dominierende Merkmal der Arbeitsablaufe. ServiceTec ist fiir eine ganze 
Reihe von international anerkannten Prozessstandards zur Softwareentwicklung 
zertifiziert, mit CMMI, PCMM, Six Sigma und ISO 900X seien hier nur die 
bekanntesten erwähnt. Sind diese Zertifizierungen zwar auch immer demons- 
trativer Qualitätsausweis, der in erster Linie an die Kunden gerichtet ist, die auf 
solche Zertifizierungen als vertrauensbildende Maßnahme großen Wert legen, 
so sind diese Prozessmodelle jedoch auch in der betrieblichen Arbeitsrealität 
von ServiceTec von großer Bedeutung. In der Praxis sind diese unterschiedlichen 
Prozessvorgaben - wie im vorigen Abschnitt bereits erwähnt - von ServiceTec zu 
einem firmeneigenen „Set“ von angewandten Prozessen verknüpft worden. Das 
in der Praxis „gelebte“ Modell ist somit kein reines CMMI-Modell oder folgt nicht 
ausschließlich Six Sigma, sondern stellt eine Kombination aus unterschiedlichen 
Elementen der verschiedenen Standards dar. Diese Prozessmodelle strukturieren 
die Arbeitsabläufe auf unterschiedlichen Ebenen. 

Auf der obersten Ebene werden in diesem Prozessmodell die unterschiedli- 
chen, von Service Tec durchgeführten Projektarten spezifiziert. So gibt es jeweils 
unterschiedliche Prozesse für z.B. Entwicklungs-, Wartungs- oder Implementie- 
rungsprojekte. Jedes dieser verschiedenen Projekte erfordert unterschiedliche, 
vorgegebene Abläufe und Arbeitsschritte. Diese werden in den Prozessbeschrei- 
bungen spezifiziert: 


„It varies actually from projects, there is nothing like: these many fixed 
processes that need to be followed. It varies based on the kind of project, 
that you do. It normally varies based on the services, that you provide and 
based on the domain area, where these services are provided. So, it varies. 
So, there are around 10 to 11 kinds of services, that ServiceTec provides, so 
it varies, the process varies for different services.“ (SI3) 


Ein anderer Projektmanager erganzt: 


„Es hängt davon ab, was für ein Projekt das ist. Es gibt zig Arten von 
Projekten. Es gibt Entwicklungsprojekte, Re-Engineering-Projekte, Kon- 
figurations-Projekte, Beratungsprojekte, Wartungsprojekte. Und danach 
ist auch wichtig, in welcher Phase dieses Projekt sich jetzt befindet. Man 
kann ja im Prinzip immer anfangen. Und danach gibt es 12 Hauptprozesse 
- im Wartungsprojekt zum Beispiel. Und unter jedem dann gibt es wieder 
Sub-Categories. Insgesamt 1000 Punkte ungefahr. Vielleicht 800, kann sein, 
ungefahr. Mir fiel dieses Thema sehr lang aus [lacht].“ (SD8) 


So sind die Projektbeschreibungen auf dieser - obersten - Ebene zunächst eine 
Art Road-Map, welche die nötigen Arbeitsschritte ausweist, die in einem sol- 
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chen Projekt gewöhnlich vonnöten sind und durchgeführt werden sollen. Diese 
Vorgaben unterstützen damit - das ist die nächste Ebene - die Projektmanager 
bei der Erstellung der Projektpläne am Anfang eines Projektes. Ein Projekt- 
manager beschreibt die Prozessmodelle und deren Nutzung auf dieser Ebene 
folgendermaßen: 


„Ja, das nennt sich Tayloring. Und zum Anfang des Projektes - der Projekt- 
leiter muss mit dem Software-Quality-Advisor [im folgenden SQA - PF], 
intern, bei ServiceTec, die Prozesse diskutieren. Und zum Beispiel in einem 
neuen Projekt sind 1000 Schritte in einem Prozess, 1000. Da muss nicht 
jeder alles machen. Dann setzt er sich mit dem SQA einen Tag zusammen, 
dann sagt er: ‚Ja, das brauche ich nicht, das bringt mir hier nichts‘. Und 
der SQA wird dann halt die Genehmigung geben. Es gibt welche [Pro- 
zessschritte sind gemeint - PF], die mandatory sind, die müssen gemacht 
werden. Und wenn diese Sache jetzt einmal fertig ist, dann wird das auch 
befolgt. ... Und jede Jahreshälfte ... hat er nochmal einen Termin mit dem 
SQA, wo er nochmal jetzt die Punkte anschaut, die zwar taylorable waren, 
also empfohlen waren vom System, aber die nicht befolgt wurden - ob das 
sich doch vielleicht lohnt, das zu befolgen. Und auch diejenigen, die jetzt 
er macht - vielleicht macht er überflüssige Sachen, nur um den Prozess zu 
erfüllen.“ (SD8) 


Den Prozessauftakt bildet also eine Auswahl der im Projekt verfolgten Prozesse 
in enger Kooperation mit den SQA. Dies sind Beschäftigte aus einer speziellen 
Abteilung, die für die Verwaltung und Weiterentwicklung der von ServiceTec 
implementierten Prozesse zuständig sind. Als Qualitätsbeauftragte obliegt den 
SQA auch die weitere Aufsicht über die Projekte in Bezug auf die Einhaltung 
der implementierten Prozesse. Die SQA sind dabei nicht in die Projektteams 
integriert, sondern fungieren eher als externe Gutachter mit einer starken Macht- 
position gegenüber den Projektteams, da sie direkt dem Vorstand unterstellt sind 
und auch an diesen etwaige Verstösse melden: 


„Der Qualitätsberater berichtet direkt an den Vorstand. Und daher hat der 
sehr viel zu sagen. Kann sagen: ‚Das soll gemacht werden, das muss gemacht 
werden. Und ich akzeptiere so, und so nicht. Und wenn Ihr das nicht 
macht, dann müsst Ihr das halt eurem Manager erklären, und ich mache 
dann meinen Bericht an den Vorstand‘. Und daher ist Software-Qualität 
dann total unabhängig von Projektplänen. Also keine guten Freunde vom 
Projektleiter.“ (SD8) 
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Bei den aus dem Prozessmodell abgeleiteten und zu implementierenden Prozessen 
wird dabei zwischen Pflichtprozessen, solchen, die anzupassen sind, und solchen, 
die lediglich optional sind, unterschieden: 


„There are certain mandatory components, that are there, which has to be 
done, unless there is an exception, which can be justified. And there are 
guidelines, which are optional, which can be modified, and there are some 
processes, which are mandatory, but you can modify them.“ (SI3) 


Das gibt den Prozessmodellen auf dieser Ebene noch einen relativ flexiblen 
Charakter, wie ein Projektmanager feststellt: 


„Und dafür ist das System sehr flexibel. Das ist das Gute daran - es muss 
nicht das, das und das gemacht werden. Das empfehlt es zwar, aber .... die 
wichtigsten Sachen müssen erfüllt werden.“ (SD8) 


Dementsprechend ist der Anteil der anpassbaren Prozesse an den Gesamtprozes- 
sen auch am größten. 


„It's a very, very less percentage, around 10 to 15 percent is normally 
mandatory, which can not be modified, and around 70 percent is mandatory, 
but can be modified, but it is mandatory. It can be modified based on the 
processes. And around 15 to 20 percent can be optional, which you can 
follow or don’t follow.“ (SI8) 


Bei der Auswahl und der Spezifizierung der nötigen Prozesse wird der Pro- 
jektmanager durch ein firmeneigenes Computersystem unterstiitzt, in das die 
Prozessbeschreibungen integriert sind. 


»Ja, es gibt ein System, nennt sich [Name entfernt - PF]. Und wenn der 
Projektleiter einen Projektplan erstellt, kann er zuerst downloaden. Man 
hat dann gleich von einem anderen System, wo das Budget notiert wird, 
bekommt er auch die Ressourcen-Namen verkniipft in diesem Plan. Gleich 
hat man die Ressourcen-Pool, die Aktivitäten. Danach kann man dann, und 
da steht das auch, ob das jetzt mandatory ist oder taylorable ist oder emp- 
fohlen ist. Und ... kann man filtern, und dann mit dem SQA diskutieren.“ 
(SD8) 


Dieses Computersystem verknüpft die Prozessbeschreibungen also bereits mit 
den verfügbaren Beschäftigten! und dem entstehenden Projektplan, d.h. den 


12 Der Sprachgebrauch, von den Beschäftigten lediglich als „Ressources“ zu sprechen, ist dabei 
keineswegs nur dem zitierten Gesprächspartner eigen, sondern typisch für ServiceTec und 
veranschaulicht sehr schön die Haltung des Managements gegenüber den Beschäftigten. 
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aus den ausgewählten Prozessen folgenden Tätigkeiten, bzw. Arbeitspaketen. So 
kann in der Planungsphase des Projektes von den zuständigen Managern ein 
detaillierter Projektplan unter Berücksichtigung der notwendig zu erledigenden 
Arbeiten und den verfügbaren Beschäftigten leichter zusammengestellt werden. 


„When we start the project, we have a huge task of the complete planning for 
the project. During that planning we have this task of creating a complete 
task-list and then we have the task of arranging for all the resources, that are 
hardware, software or even people. So, during that project planning phase 
we create microsoft project, wherein we try to divide all the activities and 
list down all the dependencies to the minimal level possible.“ (S119) 


Die in der Planungsphase erstellten Projektpläne enthalten somit bereits eine 
Liste von zu bearbeitenden Arbeitspaketen, die aus der Zusammenstellung der für 
das Projekt nötigen Prozesse gewonnen wird. Damit schlagen die Prozessbeschrei- 
bungen dann auch auf die unterste Ebene, die konkret von den Entwicklern zu 
erbringenden Tätigkeiten, durch. Auf dieser Ebene werden die Prozessvorgaben 
zudem von weiteren Vorgaben ergänzt. 

So sind für die einzelnen Prozessschritte entsprechende Input- und Output- 
Dokumente definiert, die einen Arbeitsschritt einleiten, bzw. die zum Abschluss 
eines solchen produziert werden müssen und damit den Übergang zum nächsten 
Schritt bilden. Für diese Dokumente gibt es Vorlagen, die den jeweiligen Prozes- 
sen hinterlegt sind und die von den Mitarbeitern im Laufe der Bearbeitung der 
einzelnen Aufgaben ausgefüllt werden müssen. Diese Vorlagen sind zudem häufig 
mit Checklisten verbunden, mithilfe derer sichergestellt werden soll, dass alle 
vom Prozess vorgeschriebenen Tätigkeiten auch durchgeführt wurden, bevor der 
Arbeitsschritt als beendet gekennzeichnet wird und den nächsten Schritt anstößt. 


„And we have systems [...] for every, every aspect of project management, 
we’ve got templates, we’ve got guidelines, for everything. From require- 
ment analysis to delivery, to maintenance to support. So we have a lot 
of guidelines, a lot of templates, a lot of processes in place, which have 
developed over a period of time.“ (ST12) 


Eine andere Art von Vorgaben bzgl. der Arbeitsverrichtung stellen auch die 
sogen. „Coding-Guidelines“ dar. Diese sind als Normenkataloge zu verstehen, 
die wesentliche Konventionen für die Erstellung der Applikation, bzw. zum 
Bearbeiten eines Programmcodes enthalten. Darunter fallen beispielsweise Na- 
menskonventionen für die zu benutzenden Variablen und Funktionen sowie 
Vorgaben zur Form und Struktur, in der programmiert wird, also Einrückungen, 
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Kommentarformate etc. Bei Wartungsprojekten sind diese Coding-Guidelines 
haufig vom Kunden vorgegeben, da die Bearbeitung der zu wartenden Program- 
me zu den bestehenden Systemen und dort verfolgten Standards passen sollen. 
Bei Entwicklungsprojekten gelten hingegen die eigenen Standards. Es handelt sich 
dabei sowohl um branchenweite Standards als auch um firmeninterne Lésungen, 
die über die Zeit hinweg evaluiert und weiterentwickelt werden. 


Diese Vorgaben bzgl. der Arbeitsschritte sind in ihrer Reichweite bzw. ihrer 
Wirkung für die Arbeit der Entwickler nicht zu unterschätzen. Die folgende 
Aussage eines Managers weist in drastischen Worten auf die Detailtiefe der Pro- 
zessvorgaben für jeden einzelnen Arbeitsschritt und die daraus resultierende 
Dequalifizierung der Arbeitsaufgaben für die Entwickler hin: 


„Ihe entire organızation works fully on standards, processes, frameworks. 
For everything there’s a standard, everything there’s a document, for every- 
thing there’s a template, everything works on that. So there is, Imean, we 
have been saying that, it is becoming too ... - in a sense that: Does a person 
really need to apply a brain to do anything? There’s a form for everything. 
There’s a fixed template for everything.“ (S115) 


Auch ein anderer Projektmanager teilt in seiner Antwort auf die Frage nach 
einem persönlichen, individuellen Arbeitsstil der Entwickler diese Einschätzung: 


„Jo answer that question, no, absolutely not, nobody can code in their 
own style, we have standard guidelines for that. We have standard practices 
and guidelines on how to code a certain piece. In that guideline you will 
find that, what are the names for, naming conventions, that have to be used, 
where you will find, how much is the indentation or their space required 
before you start coding any line and you might even find, what are all the 
comments that are in that unit to put in the code. So, all these are shared 
with the developers at the beginning of the project. That is a part of the 
project planning exercise. Eh, does that answer your question?“ (SI19) 


Sicherlich mag man dem Management von ServiceTec ein Interesse daran unter- 
stellen, die Wirkung der Prozessbeschreibungen und die Kontrolle, die dadurch 
über den Produktionsprozess gewonnen wird, zu überzeichnen, doch in diesem 
Punkt decken sich die Schilderungen des Arbeitsablaufs von Seiten der Entwick- 
lerInnen weitgehend mit der Darstellung des Managements. So ist die folgende 
Entwicklerin z.B. geradezu amüsiert über die Frage nach einem persönlichen 
Arbeitsstsil bei der Programmierung: 
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[Laughs] Nooo - we do follow some coding standards, so everybody will 
code with COBOL according to the standards. [...] There are some com- 
pany standards, and we have developed our own coding standards, coding 
certificate [...] and all this.“ (ST1) 


Die Prozessbeschreibungen schlagen also mitsamt der mit ihnen verknüpften 
Vorlagen und Programmier-Richtlinien bis auf die Ebene der an die Entwickler 
verteilten Arbeitsaufgaben durch und stellen enge Vorgaben dafür dar, wie die 
Arbeitsaufgaben anschließend bearbeitet werden sollen. 


Ist in den Prozessbeschreibungen damit also schon die grobe Definition der Ar- 
beitspakete vorgesehen, so beruht die Zuweisung der Arbeitsaufgaben an die 
einzelnen Entwickler im Team dennoch auf einer persönlichen Zuteilung durch 
die Projektmanager bzw. Modulleiter: 


„These are the parts, which are coming from the guidelines, coding stan- 
dards, you have review checklist, you have review process, you have con- 
figuration management process. They are taylored based on the needs of 
the project, but primarily comes from the guideline. This would be on 
the process side. What ... the day-to-day-task would be actually designing 
and coding the system. That would be more done by the project manager, 
where the project manager will draw out the project plan and define each of 
the activities to people there, which module they have to design, which pro- 
gram they have to design, which program they have to code. For it’s. . . they 
have to follow the activities and also keep this process in mind. So whenever 
they’re coding any program, which is assigned to them, the requirements 
are explained to them by the person, who has sent requirement analysis for 
the project. [...] Now when they have to do a design, they have to follow 
the design template, which comes as an input from the guideline. They 
have to follow certain standards, that comes as an input from the guideline. 
But the time duration in which they have to complete the design, when to 
start, when to complete, who would do the design. All that will come from 
the project manager.“ (SI17) 


In der zitierten Aussage wird der Zusammenhang zwischen der Prozessseite auf 
der einen und der persönlichen Zuweisung auf der anderen Seite beschrieben. Die 
Prozessbeschreibungen und die darin enthaltenen Vorlagen und Vorgaben enthal- 
ten zwar die grundsätzlichen Informationen für die Bearbeitung der jeweiligen 
Arbeitsaufgaben. Aber die genaue Zuteilung an die beteiligten Entwickler, sowie 
die Planung darüber, was wann und in welchen Zeiträumen erledigt werden soll, 
ist Sache der Projektverantwortlichen. D.h. damit auch, dass die Entscheidung 
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über die Lange der Arbeitspakete letztlich nicht direkt aus den Prozessbeschrei- 
bungen abgeleitet wird, sondern eher den Modulleitern obliegt, die den nötigen 
Arbeitsaufwand schätzen. Selbstverständlich wird diese Schätzung durch Firmen- 
standards unterstützt: 


F: So, you never know, how much time a certain task will take? 

„We do know the time, that is - it really varies, say for example, there is 
an enhancement, that I get, which might be something like, it will require 
a new field on the screen, because a new kind of tax has come from the 
government, which needs to be accommodated. That could be one kind 
of an enhancement. The other kind of an enhancement is, where, eh, the 
government has imposed a new rule in calculation of the premium for 
this insurance client. So, obviously these two enhancements are going to 
take different timeframes for executing. So, we do have a guideline for 
estimation, saying that, if these are the number of business tools that are 
getting modified, then this is the effort for this and these are the number of 
screens that have to be modified, then this is the effort for this. So, based on 
that, we come up with an effort for each and every enhancement. So, in this 
enhancement, if there are quarters like, say, 10 percentage or 20 percentage, 
and based on the 20 percentage and based on the experience that we had, 
or based on the data we had in this project earlier, we split into different 
software life cycles. So, really the thing varies between two enhancements. 
We do know the timeframe, but it varies between two enhancements and 
there is no guideline, which says, that this is to be followed. The guideline, 
which is there, is the common guideline, which is there for the entire 
software industry, which says that: this much has to be (percentage of the 
effort) has to be requirements, this much percentage of the effort has to be 
design, this much percentage has to be the build. Which again varies on a 
project to project basis, because there are projects, which are build-intensive, 
there are projects, which are design-intensive, so it really again varies based 
on the project. So, on timeframes, generally there are no guidelines during 
the execution. But the guidelines can be set up at the project level.“ (S13) 


Die Firmenstandards in Bezug auf die Zeitspannen der Arbeitspakete leiten sich 
also nach Angaben dieses Projektmanagers aus den Erfahrungen der Firma ab. 
Dazu werden alle Projekte regelmäßig evaluiert und auf die benötigte Zeit der 
einzelnen Arbeitsschritte hin untersucht und verglichen. Die daraus gewonnenen 
Durchschnittswerte bilden dann die Grundlage für die weiteren Schätzungen 
der Arbeitsaufwände für die Aufgaben der Entwickler, wie ein Projektmanager 
ausführlich erläutert: 
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„See, basically this is, this is mainly after that the requirements analysis 
phase. Ok. So we do..., what we have done, the requirements detailing, 
we know all the requirements, that are there for the development of any 
application. And then these requirements come into design. The design is 
the technical implementation of the requirements. On probably converting 
it into a solution. So, once we have the design with us, probably you can call 
it a high-level design, we will know allthe components, all the components 
and all the, yeah, all the components, that have to be developed for an 
application. Ok, once we know all those components, that have to be 
developed, we will also know the dependencies across these components 
or any external dependencies. So, now, my estimation model, the standard 
estimation model, that we have, actually that estimation model has been 
developed using the passed data in the industry best practices. So that 
estimation model would give me that effort required at each and every 
component level. So, now, taking that effort required, we know, that this 
much would be the effort, that would be completely required to develop 
one component. And after that we have guidelines within the organization 
on how much out of that total effort, how much percentage should go into 
development, how much percentage should go into testing and all that. So, 
then we apply that percentage distribution and come up with the effort 
required. So, using these techniques and tools, you will get a meticulous 
level of effort, effort at the lowest level.“ (S119) 


So sehr daher also die Prozessmodelle auch als strukturierendes Element der 
Arbeitsorganisation bei ServiceTec betont werden, so beruht die Definition und 
Zuweisung der Arbeitsaufgaben nicht ausschließlich auf ihnen. Sie geben einen 
Rahmen und definieren Tätigkeiten, die für einen bestimmten Prozess ausgeführt 
werden müssen. Die konkrete Gestalt der in diesen Prozessbeschreibungen ent- 
haltenen Tätigkeiten wird jedoch zusätzlich noch durch die Feinplanung durch 
die Projektverantwortlichen, also den Projektmanager, häufig in Kooperation mit 
dem Modulleiter, beeinflusst. Diese legen die genauen Zeitrahmen der Aufgaben 
fest, entscheiden, wie die Arbeitsaufgaben auf die Entwickler verteilt werden. 
Somit können die Arbeitsaufgaben der Entwickler nicht ausschließlich als Aus- 
druck der bei Service Tec implementierten Prozessmodelle gesehen werden. Ihre 
konkrete Gestalt ist auch Ergebnis zusätzlicher Gestaltung durch die Projektlei- 
ter. 


Die strategische Orientierung Service Tecs bei der Gestaltung der Arbeitsaufgaben 
ist dabei eindeutig. Es wird versucht, die Arbeitsaufgaben für die Entwickler 
möglichst eng zu definieren und die Arbeitspakete damit zeitlich soweit wie 
möglich herunterzubrechen, wie ein Projektmanager erläutert: 
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„Ok, so in a Microsoft-Project® we create that task-list, in which you might 
find, that the tasks are not more than two to four hours or eight hours max. 
[...] That is the level of planning, that we do. Yeah, we do plan for the task, 
that would be probably two hours, four hours or eight hours at the most. 
And then using that MSP only we start locating the tasks to the people.“ 
6119) 


Der Grad zu dem die Arbeitspakete fiir die Entwickler heruntergebrochen wer- 
den können, unterscheidet sich dabei allerdings zwischen den unterschiedlichen 
Projektarten. Nach Angaben der betroffenen Entwickler unterscheiden sich die 
Arbeitspakete in Entwicklungs- und Wartungsprojekten in ihrer Länge deutlich. 
So können die Zeitrahmen, der an die Entwickler zugewiesenen Arbeitspakete 
in Wartungsprojekten noch einmal wesentlich kürzer sein, als die benannten 2-8 
Stunden. 


„Ihe shortest period - that normally comes in a production support request, 
where you get a request in the morning and you have to deliver it in the 
evening. Such is, can be the shortest duration. And there are tasks, which 
are, like, one hour duration, where you need to do the release audit for this 
particular project, so it normally takes one hour, or you do a review, which 
normally takes one hour.“ (SB) 


Die angegebene Zeitspanne von 2-8 Stunden muss dabei auch in Entwicklungs- 
projekten eher als strategische Zielgröße angesehen werden, denn als durch- 
schnittlicher Wert. So ließen sich bei den untersuchten Projektteams, die mit 
einer Entwicklungsaufgabe betraut waren, durchaus auch längere Arbeitspakete 


finden: 


„It’s usually a weekly. In our previous project it used to be, like, one or two 
days actually. Like in our previous project it was a lot of maintenance part 
of it, like, they have to fix it within one day. So the tasks were allocated to 
them on a daily basis. So here we are doing a build project. So build goes 
for one week, two weeks actually. So they have their work on it for those 
two weeks.“ (S114) 


Damit ist jedoch nicht gesagt, dass ein Planungshorizont von 2 Wochen auch 
bedeutet, dass in diesen 2 Wochen der Fortschritt der Arbeiten nicht haufig 
kontrolliert wird. Der Frage der Kontrollzyklen und der Haufigkeit der Kon- 
trollen wird sich das nächste Kapitel noch ausführlicher widmen, aber es kann 


® ServiceTec setzt Microsoft Project als Software fiir das Projektmanagement ein, der Interview- 
partner bezieht sich hier auf einen in MS Project erstellten Projektplan, im folgenden MSP 
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festgehalten werden, dass auch wenn für Arbeitsaufgaben teilweise mehr als ein 
Tag kalkuliert werden, für diese Zeit Zwischenschritte eingeplant werden, mit 
denen der Fortschritt kleinschrittig - häufig täglich - erfasst werden kann. 

Die Arbeitsaufgaben werden bei Service Tec jedoch nicht nur möglichst kurz- 
taktig definiert, sie werden auch rotierend den einzelnen Entwicklern zugewiesen, 
wie ein Modulleiter erläutert: 


„See, the tasks involved in a problem notification solving is ... finding the 
problem, finding the solution, testing that solution and testing various parts 
of the unit testing and system testing. So we randomly associate different 
people so that everybody is capable of doing everything.“ 

F: So it doesn’t matter at all who is assigned which task? 

„Yes, that is more to avoid the dependency on any particular person.“ (S120) 


Weiter oben wurde bereits auf die Flexibilität der Rolle des Entwicklers hingewie- 
sen und die organisatorischen Maßnahmen beschrieben, mit denen versucht wird, 
eine fachliche, technische oder regionsabhängige Spezialisierung der Entwickler 
zu vermeiden. Doch die Entwickler wechseln zu diesem Zweck nicht nur regel- 
mäßig die Projektteams und werden abteilungsübergreifend verschoben, sondern 
auch während der Zeit in einem Projekt bekommen die Entwickler möglichst 
rotierende Arbeitsaufgaben zugewiesen. Durch diese Art der Aufgabenzuteilung 
soll ebenfalls eine fachliche und projektspezifische Spezialisierung vermieden 
werden. Dadurch wird einerseits die Abhängigkeit der Projekte von einzelnen 
Personen weiter reduziert und andererseits sollen die Entwickler dadurch befä- 
higt werden, alle Arten von im Projekt anfallenden Tätigkeiten auszuführen. Aus 
diesem Grund werden auch etwaige Vorerfahrungen der Entwickler von den 
Modulleitern bei der Aufgabenverteilung nicht berücksichtigt: 


F: You said that you are trying to rotate the tasks, does it happen that some 
team members are more experienced and get assigned the more complex 
tasks? 

„No, I don’t see that happening.“ (S120) 


Besonders deutlich wird dieses spezielle Vorgehen in Vergleichen zu den deut- 
schen Counterparts beim Kunden, die indische Entwickler anstellen: 


„One more difference would be - they [die Beschäftigten beim Kunden 
- PF] will stick to that technology probably throughout their lives. But 
we don’t get a chance to do that here. We normally become the jack of all 
trades and master of none.“ (SI20) 


In anderen Worten formuliert eine Entwicklerin dieselbe Beobachtung: 
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»Actually, what I have seen in IT-people at [Deutscher Kundenname - PF] 
and in IT-people in India is, that they are specialized in certain fields. But 
here in India, what is done, is, that we have to work in all types of things. 
We are not masters of..., let’s say..., we are not..., we have to be masters of 
all the things, actually. But in their cases I’ve seen, they send people, who 
are specialized in different tasks. So one kind of task will be handled by 
one person only and he’ll keep on handling that task only, he’ll be perfect 
in that. In our case, we work in all the jobs.“ (S121) 


Auf der Ebene der Entwickler versucht ServiceTec also, Spezialisierungseffekte 
gezielt zu verhindern und zu unterlaufen. Dies ermöglicht ServiceTec, die Ent- 
wickler intern flexibel einzusetzen und auch nach Bedarf zwischen verschiedenen 
Projekten und sogar verschiedenen Business Units zu verschieben. Ein Delivery 
Manager formuliert diesen Vorteil der Aufgabenorganisation wie folgt: 


„People have spent enough energy taking the best practices, that they 
have learned across and then created these artifacts: For this, follow this 
particular process. So that’s what also... keys of standardization. When I 
move, let’s say tomorrow from [Name der fiir u.a. Kunden in Deutschland 
zustandigen Abteilung - PF] to any other group, I don’t know, no need to 
figure out what that group is doing. Pll go there and I get the same things.“ 
(S115) 


Dabei ist dieses Rotationssystem für ServiceTec nicht unproblematisch. Zwar 
will man natürlich die flexiblen Einsatzmöglichkeiten erhalten, doch gibt es auch 
eine Grenze für dieses Bemühen. So stellt das branchenspezifische Wissen der 
Beschäftigten auch für ServiceTec eine wichtige Ressource dar. Wenn die Beschäf- 
tigten das Geschäftsumfeld des Kunden kennen, so erleichtert dies durchaus die 
Kommunikation mit dem Kunden, da die Entwickler die Anforderungen an 
die Software besser verstehen können. Stetige Rotation zwischen verschiedenen 
Geschäftsfeldern stört jedoch den Aufbau dieses Branchenwissens empfindlich. 
Daher wird bei ServiceTec versucht, die Beschäftigten möglichst nicht übermä- 
Big zwischen verschiedenen Branchen zu rotieren, sondern sie in Projekten für 
eine bestimmte Branche zu halten. Nach den bei Service Tec durchgeführten 
Interviews zu schließen, gelingt dies jedoch nicht immer, denn diesem Bemühen 
werden vom Geschäftsaufkommen Grenzen gesetzt. Wenn es in einem Bereich 
nicht genügend Bedarf an Beschäftigten gibt, werden diese auf andere Projekte 
verschoben, wie eine Entwicklerin klarstellt: 


„Yeah, we have one option, that we can obviously go to our senior and tell 
him, we are interested, this is, what I want. If it’s possible, we are given the 
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opportunity, and if it’s not, then obviously we have to shift, wherever we 
are asked to.“ (SI21) 


In der Praxis führt dieser Widerspruch zu einer Mischung aus Beschäftigten, die 
durch verschiedene Kundenbranchen gewechselt sind und auch weiter wechseln, 
und anderen, die sich zunehmend in einer Branche spezialisieren und auch gezielt 
in diesen Bereichen gehalten werden sollen: 


„Ihere is a special team which is working only for Austria, Switzerland 
and Germany. Each practice has identified a set of people. And those 
people are owning that practice, it will be only those people, who would 
be working for Austria, Switzerland, Germany practices and they would 
not be working for any other practice, as long as work is there in Austria, 
Switzerland Germany practice. Let’s say, there is a little bit of downturn, 
and those specific skills are not required, then yeah, they can be moved to 
another practice and work there. But if there is a work there and there is a 
requirement there, it would continue working with that practice, they are 
owned by that practice, where they are used to work. .... [...] The reason, 
why we have the same people working within the practice, is, because at 
one level, we understand that..., let’s say in UK, where we are verticalised 
14 we want the people, who are working in the practices there, to bring 
in their industry knowledge, you know? Because, let’s say, of course he is 
working in financial services with a financial services client, next time we 
move him to, say, a pharma client, he would bring less value to the client, 
which is not really, what we want. That is why we retain it that way.“ (SI4) 


Hier wird also anscheinend versucht, eine Balance zwischen der Rotation und 
der Reduktion der Abhängigkeit von einzelnen Beschäftigten auf der einen 
Seite und der Notwendigkeit, in einem Geschäftsfeld erfahrene Beschäftigte mit 
Branchenkenntnissen auszubilden auf der anderen Seite, zu finden. 

Neben dem flexiblen internen Einsatz der Entwickler ermöglicht diese Form 
der Aufgabenorganisation ServiceTec auch, mit externer Personalfluktuation 
leichter umzugehen. Die Zeit, die benötigt wird, um einen aus dem Projektteam 
scheidenden Entwickler durch einen anderen zu ersetzen, werde nach Anga- 
ben von Beschäftigten auf diese Weise stark verkürzt, da die Einarbeitungszeit 
reduziert werde. Dieser Aspekt wird im späteren Kapitel über die Arbeitsmarkt- 
beziehungen noch zu vertiefen sein, jedoch kann an dieser Stelle bereits festgehal- 
ten werden, dass sich hier die für den indischen Standort so charakteristischen 


14 Gemeint ist eine Aufteilung der Geschäftsbereiche über eine regionale Aufteilung hinaus. In 
Deutschland ist bisher noch nicht genug Geschäftsvolumen verfügbar, um zwischen verschiede- 
nen Branchen organisatorisch zu unterscheiden, dies ist in UK oder den US jedoch anders. 
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Fluktuationsraten entscheidend in der Firmenstrategie zur Kontrolle der Arbeit 
niederschlagen und die spezifische Form der Aufgabenorganisation wesentlich 
(mit-) gepragt haben. 


Dem bisher skizzierten Vorgehen bei der Aufgabenorganisation entspricht auch, 
dass Mitspracheméglichkeiten bei der Zuteilung der Arbeitsaufgaben für die Soft- 
wareentwickler kaum gegeben sind. Auf die Frage, ob sie ihre Arbeitsaufgaben 
mitbestimmen könne, antwortet eine Entwicklerin leicht verlegen: 


„No, we don’t do it actually. We don’t have the right to do it maybe. [lacht 
leicht verlegen].“ (SI1) 


Ein Projektmanager wittert hinter dem Wunsch, bei der Aufgabenverteilung mit- 
zubestimmen gleich das Verlangen nach inhaltlicher Spezialisierung, wenn er auf 
die Frage, ob die EntwicklerInnen Mitsprachemöglichkeiten bei der Verteilung 
der Arbeitsaufgaben haben, antwortet: 


„No, usually not. They are usually ... they don’t actually. If they want to 
specialize we give them, we have certification plans, actually. Like you can 
study those technical things and give certifications. That they can pick up. 
But work-wise eh within project, they cannot choose what they want to 
do. Usually they don’t come back to us saying that they don’t want to do 
it. It rarely happens.“ (S114) 


Und auch ein Modulleiter unterstreicht diesen Eindruck eher unfreiwillig: 


F: Do you discuss the distribution of tasks with your software engineers? 
„Yah, we keep asking them also: are you comfortable doing all this, will 
you be able to complete in the equivalent time?“ 

F: And it’s also possible to say: ‘No I don’t like the task I want another 
one?’ 

„No, this never happened. ... They are comfortable doing it ... mostly.“ 
(S122) 


Probleme und Widersprüche der Aufgabenorganisation 


Betrachtet man die Praxis der Aufgabendefinition und -verteilung bei ServiceTec, 
so ist es wenig überraschend, dass die an Entwickler vergebenen Arbeitsaufgaben 
meist nur geringe kreative Anforderungen an diese stellen und dementsprechend 
auch als monoton und der eigenen Beeinflussung entzogen wahrgenommen 
werden. Die folgenden Äußerungen einer Entwicklerin bzgl. ihrer täglichen 
Arbeitsaufgaben bestätigen diese These plastisch: 
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„Boah .... [laughs] Boring ... boring I can say in the end, when there were 
lots and lots of reports and ok, I used to say: ‘Ok, this is the same whole 
thing I have to do.’ Yah, that time, in the end ... Because I think I coded 
more than seven reports in a row. So in the end it was like: Ohhh, one more 
report to go. And that time it did become a little monotonous ...I should 


say. Not boring, but yah, monotonous is... It became quite monotonous, 
as in, ok, same whole XML-XSL-testing and all. (S12) 


Ein anderer Entwickler teilt diese Ansicht: 


F: What are the most interesting or most challenging parts of your working 
tasks? 

„Most challenging part of it ... normally associates not with technology, but 
with understanding the business aspect behind it. The business is pretty 
complex when it ... whichever field you go to, be it banking or be it retail 
- the business part is the complex part. Putting the technology behind it, 
putting the code behind it is - not as thrilled. So, yes, understanding the 
business part is the most challenging part of it.“ 

F: And what are the most boring parts? 

»Most boring part is ... screening processes again and again for everything. 
At time it gets boring. Even for a small change you have to do a intensive 
testing. It becomes monotonous at those times.“ (S120) 


Dieser Entwickler findet bezeichnenderweise genau jene Tatigkeiten interessant, 
die er als Entwickler gar nicht bearbeitet. Dass er trotzdem Erfahrung mit dem 
Geschäftsumfeld der Kunden hat, und daher weiß, wie spannend es ist, die 
geschäftlichen Hintergründe hinter der technologischen Umsetzung zu verste- 
hen, liegt daran, dass dieser Entwickler im Zuge einer kurz bevorstehenden 
Beförderung bereits erste Aufgaben eines Modulleiters - sozusagen „zum Test“ - 
übertragen bekommen hat” und daher gegenüber „reinen“ Entwicklern bereits 
ein umfassenderes Tätigkeitsprofil besitzt. 

Eine andere Entwicklerin arbeitet in einem Maintenance-Projekt und fühlt 
sich weniger inhaltlich als vielmehr durch den permanenten Zeitdruck herausge- 
fordert: 


F: If you look at the working tasks you have to perform on a day, what 
would you think, are the most challenging tasks? „Eh, most challenging 
tasks are, eh, one of them was like yesterday eh, yesterday’s tasks, when 
actually you have to solve the issue immediately, you don’t have any time 
to think or whatever, you just need to fix it as soon as possible. And the 


5 Zu weiteren Fragen der Beförderungen bei ServiceTec, siehe auch Kapitel 5.3.4 
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client is pushing you, that it’s really urgent, because it’s on the live side and 
people are visiting it very frequently. In that case you really need to rush 
up and if you are not aware of the flow, it’s really difficult to get things 
solved. And otherwise, if we have time or we have some daily requests, that 
are routine level requests, in that cases, it’s ok.“ F: And the most boring 
tasks? „Most boring tasks are while using this content management tool, 
when we make the changes on the live servers [lacht] because they are 
really monotonous and they come every day, because every day we have a 
little bit of changing, one or two of the sites.“ (SI21) 


Dieselbe Entwicklerin ist es dann auch, die ihre Ansicht über den Arbeitsalltag, 
den sie als monotone Routine erlebt, auf den Punkt bringt, indem sie in Reaktion 
auf den Dank für das Interview antwortet: 


„It was a real nice interview [...] It’s really different from the monotonous 
routine, that I have over the day.“ (SI21) 


Eine andere Programmiererin führt aus, dass sie sich in ihrem Projekt stark 
unterfordert fühlt. Ihr obliegt die Wartung einer bestimmten Unterfunktionalitat 
eines Programmes, die Abhängigkeiten zu den anderen Teilen der Applikation 
sind ihr im wesentlichen unbekannt: 


„Work-wise - yah, I mean it’s really difficult initially to know the entire big 
system. You’re given some defect or some ... some work and you'll not be 
knowing the whole module, even if you know some programs. Or what 
is the impact that it is going to make, if you’re making ... a small change 
in some part, how is it gonna impact the other parts and all. [...] Since it’s 
a maintenance project you'll do some enhancements and you just have to 
find out where’s the problem and change it and fix it. So it’s not a very... 
very big challenge or something [spricht den letzten Satz leiernd].“ (SI1) 


Dem von ihr geäußerten Wunsch nach anspruchsvolleren Aufgaben wurde in der 
letzten Zeit nicht entsprochen: 


„So Pm like ... for the past six months I have been telling that I want 
something challenging, I want something different, new, because I am used 
to - I know the system now. I can finish it fast and there’s nothing I did, 


which broke my head.“ (SI1) 


Dementsprechend wirkt die Schilderung ihres Arbeitstages auch wie ein Warten 
auf den Feierabend: 


„Nowadays average has become there’s one bug a day. So [laughs] I mean - 
it gets over! Morning, when I come, I reach by 10 o’clock. Then I check - 
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then I see whether I can understand the bug or not. Then I start working 
on it. By five o’clock it gets over.“ (SI1) 


Ahnlich wie bei der zeitlichen Lange der Arbeitspakete zu beobachten, unter- 
scheidet sich auch die Attraktivitat der Arbeit zwischen Entwicklungs- und 
Wartungsprojekten. Dabei spielt eine große Rolle, dass man sich bei Wartung 
und Erweiterung einer bestehenden Applikation an der bestehenden Architektur 
der Applikation orientieren muss, was die eigenen Gestaltungsmöglichkeiten ein- 
schränkt. Zudem handelt es sich in diesen Projekten meist um weniger komplexe 
Arbeitsgegenstände als bei Entwicklungsprojekten. So berichtet eine Entwickle- 
rin aus einem Maintenanceprojekt: 


„We had to follow the same pattern [as the rest of the already existing 
application - PF], because it was a typical Java project, a web application, 
where is a three-tier architecture [dreischichtige Systemarchitektur] and all. 
Code-wise we couldn’t make more changes. We didn’t have options.“ (SI2) 


Sie wünscht sich daher auch, zukünftig eher in Entwicklungsprojekten eingesetzt 
zu werden: 


„Yes, exactly. I think that's the main difference between a development 
and a maintenance. Because it was a maintenance I was supposed to follow 
whatever is been previously done by my seniors or whatever is been done 
by the client itself. And I think, if it’s a development, then a coder can 
create .... can have his own ideas, can put forth his own ideas to the manager: 
‘Ok, we can do it... we can do it in this way, it might reduce time, or it 
might increase the performance.’ But I was unlucky to ..., as in Pve never 
been a part of development projects. Initially, when I was a fresher I was a 
part of a development project, but that time I was extremely new. I didn’t 
know, I couldn’t put forward my ideas at that time. But once I got to... got 
well-wise with the projects, I was put into maintenance. So there was not 
much of creativity to be shown.“ (SI2) 


Wie anhand solcher Aussagen von Entwicklern anschaulich gezeigt werden kann, 
bleiben die Effekte der Form der Aufgabenorganisation auf die Beschaftigten 
nicht aus. Die Darstellung der Aufgabenorganisation bei ServiceTec ware aller- 
dings unvollstandig, wenn nicht auch erwahnt wiirde, dass deren immanente 
Widersprüche den Führungskräften bei Service Tec durchaus bewusst sind. Eine 
Modulleiterin beschreibt das Dilemma in folgenden Worten: 


„Say if you are fixing a particular problem and in the same architecture you 
can fix it in more than one way. And it is possible that the way the software 
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engineer has chosen is more innovative and more performance oriented 
than the way you are thinking. That is also a possibility. So if we cut the 
idea at that instance itself, then we, he will not be able to put forth his ideas 
and put forth his way. But if it, if what he has implemented is not correct 
or is not performant enough, then you can always ask him to change it. 
But if you start telling him from the beginning, he would never be able to 
analyze the things on his own and that is growth as well. So we make sure 
that the person analyzes things and gets the hands on the code and we also 
see that it is performant enough and it is, it complies to the architecture 
and it doesn’t affect other pieces of the code. There is a balance that has to 
be brought in place.“ (ST12) 


So besteht bei ServiceTec also durchaus ein Bewusstsein dafiir, dass das Vorgehen, 
den Beschäftigten sehr kurze, wenig komplexe und kleinteilig vorspezifizierte 
Arbeitspakete zuzuweisen, die qualifikatorische Entwicklung der Beschäftigten 
unterminieren kann, was langfristig nicht zum Wohle der Firma sein könnte. Mit 
ihrer Forderung nach einer „Balance“ zwischen Selbstorganisation und Anwei- 
sungen durch Vorgesetzte stellt die zitierte Modulleiterin bei Service Tec jedoch 
eine Ausnahme dar. 

Auch ein Vertreter des hohen Managements weiß, dass die Form der Aufga- 
benorganisation Unzufriedenheit auf Seiten der Entwickler auslöst: 


„If you say ‘No, process is the only way you can achieve your aim and you 
can’t change it’, then people will say: Hell with you! Iknow more then 
what is there.“ (SI9) 


Das Bewusstsein für diesen Widerspruch hat aber auf der operativen Ebene nur 
geringe Auswirkungen. Grundsätzlich gesteht der folgende Interviewpartner den 
Entwicklern die Möglichkeit zu, eigene Ideen und Ansätze einzubringen. Jedoch 
setzt er solche Vorschläge gleich unter Beweispflicht: 


„Now when I go there and say I’m doing it my own way, this is better, then 
they have to prove it is better. If they prove it is better, it goes as process, 
others have to follow. If they can’t - then they have to follow what is there.“ 
G17) 


Die Beschäftigten können also an der punktuellen Verbesserung der Prozesse 
partizipieren, ja sollen dies sogar. Mit Einflussnahme auf die Art der Ausführung 
der täglichen Arbeitspakete hat dieses Verständnis allerdings sehr wenig zu tun. 
Zudem ist angesichts der knappen Zeitrahmen der Projekte bei Service Tec und 
der Komplexität der Planungen leicht ersichtlich, dass es für die Entwickler nur 
sehr schwer möglich sein wird, die Überlegenheit ihres Ansatzes zu beweisen. 
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Des weiteren wird von Projektmanagern auch nicht bestritten, dass eine Spezia- 
lisierung auf bestimmte Bereiche und die Erlangung von Erfahrungswissen von 
Entwicklern in eben jenen Bereichen durchaus zu besseren und vor allem schnel- 
leren Ergebnissen führen könnte. Doch zu stark ist die Angst vor Abhängigkeiten 
von einzelnen Personen, die die Fähigkeit der Firma limitieren würde, Beschäftig- 
te flexibel zu verteilen und die Firma verlassende Beschäftigte schnellstmöglich 
zu ersetzen. So wird dieses Dilemma bei ServiceTec durchaus bewusst durch 
Verzicht auf Spezialisierung zugunsten einer höheren Unabhängigkeit von ein- 
zelnen Personen aufgelöst. Die bei Service Tec dominierende Haltung gegenüber 
Entwicklern drückt sich beispielhaft in folgender Aussage eines HR-Managers 
zum Beförderungsprozess bei ServiceTec aus: 


„As in moving to senior level, mid management and senior levels, we’d 
also have ... not only loading the person with work to see, whether the 
person is able to cope, but stress by doing multiple things, larger reporting, 
you know, unstructured way of work, etc. and all this stuff. Work in 
different areas, other than the core track itself. We’ll also do an interview 
to see, whether the person can think, not only do, but can also think that way, 
independently. [...] It is more than just the execution of routine activities. 
[...] Because sometimes, because the person, if he’s doing the same kind of 
work for two, three years, can easily take on the next responsibility in terms 
of executing. But the thinking may not hold this. So we, when we move 
people, we not only want doers, we want thinkers also, as in: it’s a mix of 
thinkers and doers as they .... go up the hierarchy. (SI7 - Hervorhebungen 
durch den Verfasser) 


Die demonstrative und überraschend deutliche Entgegensetzung von Ausführung 
auf den unteren Stufen und erst mit Beförderung in höhere Positionen notwendig 
werdender Fähigkeit zum eigenständigen Denken spiegelt beispielhaft die bei 
ServiceTec vorfindbare Form der Aufgabenorganisation wider. 


5.3.2 Kontrollstruktur 


Die Untersuchung der Aufgabenorganisation bei ServiceTec hat ergeben, dass die 
allgegenwärtigen Prozessbeschreibungen ein ganz zentrales Mittel zur Definition 
und Zuweisung der Arbeitsaufgaben an die Entwickler sind. Ebenso konnte 
gezeigt werden, dass diese Prozessbeschreibungen bereits ganz wesentliche und 
detaillierte Vorgaben darüber enthalten, wie die jeweiligen Arbeitsaufgaben zu 
bearbeiten sind. Bei diesen formellen Vorgaben handelt es sich demnach um 
sehr weitreichende Instrumente, die Handlungsmöglichkeiten von Entwicklern 
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- bei leichten Unterschieden zwischen den verschiedenen Projektarten - stark 
einschränken. Auch wenn diese Instrumente von ServiceTec als sehr vertraulich 
behandelt werden, und die konkreten Prozessbeschreibungen im Rahmen die- 
ser Studie leider nicht direkt eingesehen werden konnten, so lässt sich aus den 
Beschreibungen der betroffenen EntwicklerInnen und der Module Leads doch 
deutlich ersehen, dass diese Prozessvorgaben und Templates bis in die Program- 
mierdetails hineinreichen und den Arbeitsprozess auch auf der individuellen 
Ebene stark strukturieren. 

Die Prozessbeschreibungen stellen bei Service Tec auch ein zentrales Element 
der Kontrollstruktur dar, da sie die Art der Bearbeitung durch die Entwickler 
anleiten und auch als Vorgabe behandelt werden, gegen welche die von den 
Entwicklern geleistete Arbeit überprüft und bewertet wird. Dabei lassen sich 
verschiedene Ebenen unterscheiden, auf denen Prozessbeschreibungen auch für 
die Kontrollstruktur relevant werden. 


Anleitung und Anweisung 


Zunächst beinhalten die an die Entwickler verteilten Aufgaben stets nähere 
Vorgaben hinsichtlich der in diesem Arbeitsschritt zu erstellenden Dokumente, 
Code-Artefakte o.ä. Nach Angaben der Entwickler enthalten diese Vorgaben 
zumeist neben ausführlichen Informationen zu der Art und Weise, in der die 
Arbeitsaufgabe bearbeitet werden soll, zudem Checklisten, mit deren Hilfe die 
Entwickler am Ende jedes Arbeitsschrittes einen ersten Selbsttest ihrer Arbeit 
vornehmen sollen und so feststellen können, ob der ihnen aufgetragene Arbeits- 
schritt in allen Belangen bearbeitet und damit beendet ist. 

Wenn nach diesem ersten Selbsttest der Entwickler die Arbeitsaufgabe als 
erledigt gekennzeichnet hat, folgt ein weiterer Testzyklus, in dem die Entwickler 
untereinander ihre Arbeiten gegenseitig kontrollieren und gegen die Vorlagen und 
Vorgaben testen. Diese gegenseitigen Testphasen werden durch spezielle Systeme 
bei Service Tec computertechnisch unterstützt. Ein Projektmanager erläutert den 
Vorgang exemplarisch: 


„So what will happen is, they (die Software Entwickler - PF) will complete 
their task and depending on the configuration management process. These 
people would put that artefact into a certain location and the reviewer, 
whoever has been assigned to review the task, that reviewer can be a mana- 
ger or it can even be a peer review. Ok, so that peer or manager will pick 
up that task and in the meanwhile the developer will move on to another 
task, while the peer and manager would review his task and give, log his 
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comments in the system itself. Yeah, we have a very strong system, which 
supports the software development lifecycle stages. He would log in the 
comments into the system itself and the system would automatically send 
messages to the developer, what has to be corrected.“ (SI19) 


Das von ServiceTec genutzte System enthält also alle an den Entwicklern zu- 
geordneten Aufgaben und ermöglicht es, Teilarbeiten im Laufe ihrer weiteren 
Bearbeitung zu verfolgen. Wenn daher im Laufe des Testverfahrens Fehler in 
einem Teil gefunden werden, können die mit dem Test des Codes befassten Ent- 
wickler entsprechende Kommentare im System hinzufügen und die Korrektur 
des Fehlers wird automatisch an den verantwortlichen Entwickler zurückgemel- 
det. Auf diese Weise werden die Arbeitsaufgaben nicht nur sehr intensiv und 
formalisiert ständig überwacht, dieses System hilft Service Tec zudem, wichtige 
Informationen über die Arbeitsleistung der einzelnen Entwickler zu erheben, 
um diese entsprechend bewerten zu können. Wir werden auf diesen Punkt später 
zurückkommen. 

Die Prozessbeschreibungen und die damit einhergehenden engen und detaillier- 
ten Vorgaben sind somit ein ganz wesentliches Instrument der Kontrollstruktur 
bei ServiceTec, da sie die Verrichtung der Arbeit durch die Entwickler anleiten 
und auf der Ebene der Arbeitsaufgaben auch eine Referenzfolie bilden, gegen 
die die einzelnen Arbeiten der Entwickler anschließend auf unterschiedlichen 
Ebenen geprüft werden. 


Überwachung des Arbeitsablaufs 


Zudem bilden die kleinschrittige Planung und die kurzen Zeitrahmen der Ar- 
beitsaufgaben auch die Grundlage für eine konstante und enge Überwachung 
der Arbeitsabläufe. In dieser Hinsicht ist die Position des Modulleiters von ent- 
scheidender Bedeutung. Der Modulleiter ist die entscheidende Brücke zwischen 
dem Projektleiter und den Entwicklern. Er fungiert einerseits als fachlicher Vor- 
gesetzter für die Entwickler und hilft bei Problemen auf der operativen Ebene. 
Andererseits ist er auch für die konkrete Zuteilung der Arbeitspakete an die 
Entwickler zuständig und überwacht den Bearbeitungsprozess. Dies wird durch 
die räumliche Anordnung der Projektteams vereinfacht. Der Modulleiter befindet 
sich gewöhnlich direkt neben dem Cubicle!® des Modulteams. Er ist somit in der 
Lage, jederzeit zu sehen, woran die Entwickler gerade arbeiten. 


16 Zur räumlichen Anordnung der Projektteams, siehe auch Kapitel 5.3.1. 
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Wie bei direkter, persönlicher Kontrolle generell, gibt es in der Wahrnehmung 
dieser Kontrollfunktion durchaus Spielräume für den Modulleiter und somit 
auch Unterschiede in der konkreten Überwachung der Arbeitsprozesse. So unter- 
scheiden sich die Modulleiter der befragten Projektteams etwa hinsichtlich der 
Frequenz, in der sie sich über den Status der Aufgabenbearbeitung informieren 
und der Arbeitsfortschritt dokumentiert wird. So ist es einigen Module-Leads 
eigen, sich täglich von „ihren“ Entwicklern über den Fortschritt ihrer Arbei- 
ten unterrichten zu lassen. Andere hingegen belassen es bei weniger häufigen 
Kontrollen oder setzen eher auf informelle unregelmäßige Treffen mit den Ent- 
wicklern. Für alle Projekte gibt es jedoch mindestens einmal die Woche ein 
vorgeschriebenes Statustreffen, auf dem der Modulleiter zusammen mit dem zu- 
ständigen Projektmanager den Fortschritt der verteilten Arbeitsaufgaben formell 
kontrolliert. 


Interessant ist, dass (wie auch schon für Aktivitäten im Feld der Aufgabenorgani- 
sation konstatiert wurde) der Zyklus, in dem der Fortschritt in den Projekten 
kontrolliert wird, nicht nur durch die strategischen Ziele von ServiceTec be- 
stimmt wird. Auch hier wirkt sich der für IT-Dienstleister typische Kundenbezug 
auf die organisatorischen Formen bei ServiceTec aus. Die Kunden ServiceTecs - 
und unter diesen angeblich die deutschen noch viel mehr als z.B. die amerikani- 
schen - haben nach Angaben von Projektleitern die Präferenz, sich extrem kurz- 
taktig über den Fortschritt der Projekte unterrichten zu lassen. Dabei kommt es 
regelmäßig zu Konflikten zwischen SericeTec und dem Kunden. Ein Projektleiter 
berichtet einen solchen Fall aus seinem Projekt: 


„We do get reports on a weekly basis. And for one of my new clients, that 
I have started, actually they get a status report every day. There is a call 
of half an hour fixed every day. And my project manager gets into a call 
with their project manager and they discuss what has happened today and 
what is gonna be done tomorrow. So ... giving a status update is a part of 
our whole project management. That never gets missed out. But the fact 
that, if my project manager says, that there are 5 people who had done 
this particular task, and they have coded some x number of programmes 
... Obviously you are not seeing the program, because it’s not tested and 
delivered to you. So you have to have the trust .. that whatever this project 
manager is saying is .. is true, is not a lie. I think that’s where the distrust 
happens. Because, as I said, in software everything is intangible, you can’t 
see. I can’t make, you know, half of the code, take a photograph and send it 
to you: ‘Look, that’s where your equipment stands. It will get completed 
in four days. I can’t take a photo of the code and sent it to you, so...’. [...] 
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And a lot of customers do immediately ask, that, you know: Please, deliver 
the code! We would like to review and see how much you’ve done.“ (SI16) 


In dieser Schilderung des Projektmanagers zeigt sich sehr deutlich das Problem, 
das aus dem direkten Kundenkontakt für ServiceTec erwächst. Nach Schilderun- 
gen der Personen, die in Deutschland vor Ort bei den Kunden arbeiten, sind es 
vor allem Ängste vor schlechter Qualität der gelieferten Leistungen speziell auch 
von indischen IT-Dienstleistern, die beim Kunden dieses starke Kontrollbedürfnis 
auslösen. Dies setze sich dann bei der Auftragsvergabe nicht nur in feinmaschige 
Projektpläne mit kurzen Entwicklungszyklen um, sondern eben auch in häufige 
Statusmeldungen über den Fortgang der Arbeiten bei ServiceTec. Dabei über- 
treffen viele Kunden anscheinend mit ihren Wünschen nach Statusmeldungen 
noch den Grad, zu dem ServiceTec selbst den Fortschritt der Arbeiten erheben 
möchte. Hier zeigt sich demnach sehr schön, wie die strategische Orientierung 
ServiceTecs, vor dem Hintergrund der hohen Fluktuationsraten am indischen 
Standort die Arbeitsprozesse möglichst unabhängig von einzelnen Entwicklern 
zu machen, mit den Erfordernissen des verfolgten Geschäftsmodells in Form des 
Kundenbezuges zusammenwirkt und sich beide Aspekte gegenseitig verstärken. 


Um solche kurztaktigen Informationen über den Projektverlauf zu gewinnen 
und den Status des Projektes stetig abschätzen zu können, wird der Bearbeitungs- 
vorgang durch das gleiche Computersystem begleitet, das auch zur Verteilung 
der Arbeitsaufgaben genutzt wird und das weiter oben in diesem Kapitel bereits 
im Zusammenhang mit den gegenseitigen Testverfahren der Entwickler erwähnt 
wurde. Über dieses System - an das alle Entwickler mit ihren Arbeitsplatzrech- 
nern angeschlossen sind - erhält jeder Entwickler die vom Modulleiter verteilten 
Arbeitsaufgaben als eine Task-Liste zugeordnet. Die zugewiesenen Tasks werden 
bereits mit der vorgesehenen Bearbeitungszeit übermittelt. Damit ist der Zweck 
dieses Systems jedoch noch nicht erfüllt. Vielmehr wird es auch während der 
Bearbeitungsphase von den Entwicklern zur Erfassung der auf diese Aufgaben 
verwandten Arbeitszeit genutzt, d.h. die Entwickler dokumentieren in diesem 
Tool ihren Arbeitstag. Es ist auf allen Rechnern bei ServiceTec installiert und 
so für die Entwickler stets zugänglich. Wann immer die Entwickler eine Auf- 
gaben beginnen und beenden, wird es in diesem Tool vermerkt, genauso wie 
Pausen, Projekttreffen uvm. Nach Angabe der Entwickler wird in diesem Tool 
die verwandte Arbeitszeit sehr detailliert, teilweise sogar im Minutenbereich 
gemessen. 
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Die Überwachung der Arbeitsprozesse ist also auch auf dieser computerge- 
stützten Ebene sehr eng. Somit besteht unabhängig davon, in welchen Abständen 
der jeweilige Modulleiter sich formell im direkten Gespräch mit den Entwicklern 
seines Moduls über den Fortschritt der Arbeiten erkundigt, stets die Möglichkeit, 
den Status der Bearbeitung anhand der im System erfassten Arbeitszeiten und 
-aufwände abzuschätzen. 

Die Dokumentation der geleisteten Arbeitszeit dient dabei auf der einen Seite 
zur Abrechnung von Arbeitsstunden gegenüber dem Kunden. Auf der anderen 
Seite gehen diese Informationen jedoch auch in die interne Evaluation der Zeit- 
schätzungen für die anfallenden Arbeitsaufgaben ein. So dienen sie zur stetigen 
Weiterentwicklung des Zeitschätzungsmodells, das bei Service Tec zur Aufgaben- 
definition verwandt wird. 


„There is a system in ServiceTec, which tracks the work, eh, and the timings 
for ServiceTec purpose and there is a system with the customer, which again 
tracks hourly working hours - that is taken care of by the manager, who 
communicates with the customer. So, they have a system, which tracks on 


an hourly basis, because they are paying ServiceTec for this many hours.“ 
6113) 


Auch an dieser Stelle dient die Form der Kontrollstruktur also gleich mehreren 
Zwecken. Wie in der zitierten Aussage zu lesen, ist die exakte Erfassung der von 
den zugeteilten Entwicklern auf ihre Arbeitsaufgaben verwandten Arbeitszeit 
natürlich für den Kunden interessant, v.a. wenn es sich um ein nach Aufwand 
vergütetes Projekt handelt!’, weil die geleistete Arbeitszeit maßgeblich seine 
Aufwände determiniert. 

Auf der anderen Seite ist die Zeit, die die Entwickler für die Bearbeitung ihrer 
Arbeitsaufgaben benötigen, natürlich, wie bereits erwähnt, auch für Service Tec 
selbst interessant, da sich hier evtl. wichtige Abweichungen von den getätigten 
Zeitschätzungen für spezifische Arbeitsaufgaben, sowohl positiver als auch ne- 
gativer Art, finden, die der weiteren Optimierung dieses Zeitschätzungssystems 
dienen können. 


17 Diese Form der Projektvergütung stellt bei ServiceTec nach Angaben der Projektmanager die 
häufigste Form dar, sehr selten seien hingegen die Projekte, die per Festpreis für die gelieferte 
Leistung abgerechnet würden. 


130 Fallstudie ServiceTec 


Messung und Bewertung von Arbeitsleistung 


Schließlich gehen die Daten der Überwachungssysteme jedoch auch ganz unmit- 
telbar in die Messung und Beurteilung der Leistung des jeweiligen Entwicklers 
ein. Diese wird grundsätzlich in halbjährlich stattfindenden Treffen verhandelt: 


„That is the performance management mechanism, which we have. What 
we say is that every individual in this organization needs to be appraised by 
the manager necessarily twice a year.“ (SI7) 


An diesen Terminen wird die Leistung jedes Beschäftigten in einem recht auf- 
wändigen Verfahren bewertet. Grundlage des Bewertungsverfahrens sind Zielver- 
einbarungen, die für jeden Beschäftigten am Anfang eines Bewertungszyklus in 
Diskussion mit dem zuständigen Manager festgelegt werden und deren Erfüllung 
dann über das halbe Jahr verfolgt und anschließend bewertet wird. 

Diese Ziele beinhalten auf der einen Seite sogen. „weiche“ Ziele. Diese beziehen 
sich auf die persönliche Entwicklung des Beschäftigten in zentralen Kernkompe- 
tenzen. Dazu wurde für jede Funktion im Unternehmen ein spezifisches Set an 
Kernkompetenzen bestimmt. Die Zusammensetzung dieser Kernkompetenzen 
und deren Schwerpunkte unterscheiden sich damit zwischen den verschiedenen 
Tätigkeitsprofilen und Hierarchiestufen, jedoch enthalten sie stets eine Kombina- 
tion fachlicher und sozialer Kompetenzen: 


„For every role we identify a set of competencies. These competencies were 
in two areas: one was technical and the other was behavioral. For example - 
this is based on the job, which a person was supposed to do. For example 
for a software engineer the person is supposed to be good in programming, 
design, you know, supposed to be good at analytical ability, should be good 
in coding frameworks, methodologies etc. Those are some of the technical 
competencies. Then on the behavioral side, the person is supposed to be 
able to perform in a team, has to be a team worker, should be good at 
communicating. So those are some other behavioral competencies, which 
are identified.“ (SI7) 


Zielvereinbarungen hinsichtlich dieser „weichen“ Qualifikation der Beschäftigten 
können damit z.B. in Abmachungen über anzustrebende Fortschritte in der Kom- 
munikationsfähigkeit oder bestimmten technischen Qualifikationen bestehen. 
Solche Ziele beinhalten dann entweder die Teilnahme an bestimmten Fortbil- 
dungskursen oder firmeninternen Zertifizierungsprogrammen, oder bestimmte 
Aufgaben, die on-the job erledigt werden müssen. Ein mögliches Ziel für einen 
Entwickler kann demnach z.B. darin bestehen, im nächsten halben Jahr in 3 
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verschiedenen Technologien gearbeitet zu haben oder eine bestimmte Zahl von 
Präsentationen im Team gehalten zu haben. 

Leider konnten im Rahmen der hier vorliegenden Untersuchung nur wenige 
Beispiele vereinbarter Ziele erhoben werden, da diese im Unternehmen sowohl 
von der Seite des Managements, als auch von Seiten der Beschäftigten als sehr 
vertraulich behandelt wurden. Klar ist aber, dass zusätzlich zu diesen eher groben 
Zielvereinbarungen hinsichtlich der weiteren persönlichen Entwicklung auch 
noch ein zweiter Block Gegenstand der Zielvereinbarungen ist, der sich auf die 
Arbeit des jeweiligen Entwicklers in den nächsten 6 Monaten und deren Qualität 
bezieht. 


„In the beginning of this appraisal cycle, your manager would have set some 
goals for you. And there would be tasks set, what is expected from you in 
this, during this cycle.“ ($113) 


In Bezug auf die zukiinftige Arbeitsleistung werden demnach von Vorgesetzten 
Erwartungen formuliert, die sich mit Pünktlichkeit, Qualität, Kundenorientie- 
rung, Problemlösungsfähigkeiten und Teamfähigkeit auf fünf Aspekte der zu 
leistenden Arbeit beziehen: 


„For every grade we have a set of expectations which are very clearly 
written down. [...] There are 5 parameters. [...] The 5 parameters would 
be, one is timeliness, one is quality of work, one is customer orientation, 
one is providing optimal solution and the last is team satisfaction.“ (SI20) 


Die Aussagen der Beschäftigten zeigen, dass diese Vorgaben durchaus quantitativ 
gefasst werden. So wird häufig eine vorgegebene Fehlerrate bei der Program- 
mierung genannt, die nicht überschritten werden dürfe, und auch Erwartungen 
hinsichtlich der Abweichungen von Zeitvorgaben wurden klar und detailliert 
festgesetzt. Die Ziele, die sich auf die weitere persönliche Entwicklung bezie- 
hen, waren dem hingegen eher lockerer und qualitativer Art. Das drückt sich 
auch in dem Grad aus, zu dem die Zielvereinbarungen von den Entwicklern 
in diesen Verhandlungen beeinflusst werden können. So berichten Betroffene 
darüber, dass die Ziele hinsichtlich der zukünftigen Arbeitsverrichtung in den 
Gesprächen mit dem Vorgesetzten kaum zu beeinflussen sind, da es sich dabei 
um vorgegebene Erwartungen Service Tecs hinsichtlich der durchschnittlichen 
Fähigkeiten der eingesetzten Entwickler handelt. Etwas offener scheint die Situa- 
tion bei den „weichen“ Zielen zu sein. So berichten einige Entwickler, dass sie 
durchaus Wünsche hinsichtlich der weiteren Fortbildungskurse und technischen 
Weiterqualifizierungen äußern durften, die teilweise auch berücksichtigt wurden. 
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Ganz grundsätzlich kann aber davon ausgegangen werden, dass die Einflussnahme 
der Entwickler auf ihre Zielvereinbarungen eher gering ist. 


„Gemessen“ wird die Leistung der Entwickler schließlich in Graden der Erwar- 
tungserfüllung hinsichtlich dieser Zielvorgaben: 


„If you have done your task and have done much more than that, then 
you would be given good rating. [...] There are ratings given based on, if it 
is satisfy, satisfy prior, if it is extraordinary or under expectations or met 
expectations, beyond expectations. Based on that the ratings will be given 
on every task, which you have done during the cycle.“ (SI13) 


Der Bewertungsprozess selbst verläuft in mehreren Schritten. Auf eine Selbstbe- 
wertung des Entwicklers folgt die Bewertung durch den direkten Vorgesetzten. 
Anschließend wird in einem Gespräch über die beiden Bewertungen und eventuel- 
le Unterschiede gesprochen. Sollte sich in diesem Treffen keine Einigung erzielen 
lassen, so ein Projektmanager, so könne die Bewertung durch den nächsthöheren 
Manager entschieden werden: 


„So the process we follow: first, the person would do a self rating. Then 
the manager would do a rating. Then a competency rating - identify a 
set of development plans, identify areas of improvement. Then send that, 
the overall evaluation, back to the appraisee. Then the appraisee and the 
appraiser, they would have a discussion, and in which - if the appraisee 
agrees to what the rating said then he or she closes the appraisal saying: Yes, 
I agree to my appraisal. If there’s some kind of disagreement between the 
two, then the reviewer, who’s the next level manager, comes in place and 
tries to understand what’s the issue and tries to solve it often times.“ (SI7) 


Auch wenn die Entwickler den Bewertungsprozess bei ServiceTec grundsätzlich 
als sehr transparent und nachvollziehbar loben, bleibt der Einfluss der Entwickler 
auf ihre Bewertungen doch nach eigenen Angaben sehr begrenzt. Auch hier deutet 
sich ein kleiner Unterschied zwischen den harten, quantitativen und den weichen, 
qualitativen Zielen an. Ob sich z.B. ein nicht besuchter Fortbildungskurs negativ 
auf die Bewertung auswirkt, kann u.U. mit Blick auf Projekterfordernisse noch 
diskutiert werden. Im Gegensatz dazu wird bei ServiceTec versucht, die im letzten 
halben Jahr gezeigte Arbeitsleistung möglichst exakt zu erheben und unmittelbar 
in die Bewertung eingehen zu lassen. 

So gehen in diese Bewertung - wie bereits erwähnt - die aus der Arbeitszeiter- 
fassung gewonnenen Informationen ein. Sie liefern dem Management wichtige 
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Informationen darüber, ob der Entwickler in der Lage war, die zeitlichen Vor- 
gaben einzuhalten oder seine Aufgaben schneller oder langsamer erledigt hat. 
Ein Vertreter des höheren Managements beschreibt stolz den Umfang und den 
Nutzen der gewonnenen Informationen: 


„When you are recording on a minute by minute basis of an employee, the 
process is nothing but an input for data. So the key thing is, all the input 
you get. Today in your university, if you guys have this process, it will tell 
me what you should do. But how will the process work if the input data 
is not there? But imagine, if I would have got hold of all the data of the 
past annuals you guys have done officially in your professional lives and 
you set it to CMM and all the very powerful tools, you run them through 
that tool. I am pretty confident I would actually know what each of you is 
good at and whether you work good together in a team or not. Because I 
have that input data, I have input of hundreds of thousand of people, man 
hours, projects, on and on. [...] So, if you go to my system and press the 
key saying, you know, I am just doing some academic discussion and that’s 
it. As soon as I go back I press again and I say: cigarette break - so I'll go 
down and have a cigarette. And it’s just the key [...], so please understand, 
my own productivity is being measured at that level. And Iam not even a 
technical guy! [...] If you fix the process, if you have the input data correct, 
I am quite confident I could do the same for the two of you. If I knew 
last ten years, every minute of your activities in your professional life. So 
processes are just a set of rules, or rules engines, rather. But it’s the data 
which goes in which is important.“ (SD6) 


Auch wenn dem zitierten Manager unterstellt werden kann, die Reichweite der 
gewonnenen Informationen etwas tibertrieben darzustellen, wird doch ersicht- 
lich, wie wichtig die aus den Arbeitszeiterfassungssystemen gewonnenen Daten 
fiir ServiceTec sind. 

Doch es sind nicht nur die Ergebnisse der Arbeitszeitverwaltung, die in diese 
Bewertungen eingehen; hinzu kommen andere computergestiitzte Systeme, die 
u.a. diesem Zweck zuarbeiten. So werden auch die bereits erwahnten Systeme, die 
das Testen der von den Entwicklern geschriebenen Programmteile unterstützen, 
mit einbezogen. Neben der Schnelligkeit der Programmierung zählt schließlich 
auch die Qualität der geleisteten Arbeit. Und so können z.B. über die Testsys- 
teme Informationen darüber gewonnen werden, auf wieviel Zeilen Code der 
Entwickler wieviele Fehler gemacht hat und welcher Art diese waren. Für die 
Ebene der Entwickler stellt diese „Fehlerquote“ einen zentralen Maßstab zur 
Bewertung der Qualität der Arbeitsleistung dar und beeinflusst damit auch ganz 
maßgeblich das Ergebnis der Beurteilung. 
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Im Gegensatz zu den „weichen“ Zielen, kann nach Angaben der Entwickler die 
Bewertung in Bezug auf diese „harten“ Zielvorgaben nur sehr begrenzt diskutiert 
werden. Von daher ist der Eindruck der Beeinflussbarkeit, der vom Management 
stets erweckt wird und der dadurch scheinbar bestätigt wird, dass die Beschäf- 
tigten zunächst sich selbst bewerten und die Gesamtbewertung schließlich im 
gemeinsamen Gespräch festgelegt wird, nach Berücksichtigung der Aussagen der 
Entwickler eher irreführend. Immerhin entpuppt sich die Bewertung als ein recht 
rigider Prozess, in dem die Entwickler von Firmenseite mit fixen Leistungsanfor- 
derungen konfrontiert werden. 


Gemäß der individuellen Bewertungen werden die Beschäftigten anschließend 
in vier unterschiedliche Leistungsgruppen eingeteilt, wobei die erste Kategorie 
diejenigen umfasst, die die an sie gestellten Erwartungen übertroffen haben und 
die vierte Kategorie jene, die stark hinter den Erwartungen zurückgeblieben sind. 
Unabhängig von diesen vier Leistungskategorien werden auch alle Beschäftig- 
ten eines Projektes in ihren Hierarchiestufen nach Leistungen in eine Rangliste 
eingeordnet. Die Rangliste wird anschließend für alle Beschäftigten zugänglich 
gemacht, so dass alle sehen können, wo sie leistungsmäßig innerhalb des Teams 
stehen. Hier deutet sich schon ein Merkmal der Gestaltung der internen Koope- 
rationsbeziehungen an, das uns im folgenden Abschnitt noch näher beschäftigen 
wird: die Forcierung der innerbetrieblichen Konkurrenz unter den Entwicklern. 

Die Einteilung in die vier Leistungskategorien ist anschließend auch Grundlage 
für Maßnahmen, mit denen versucht wird, die Leistung von einzelnen, unter- 
durchschnittlich bewerteten Beschäftigte gezielt zu verbessern. Je nach ihren 
Defiziten in den verschiedenen Bereichen der Bewertung werden schlecht (Kate- 
gorie 4) bewertete Beschäftigte zu speziellen Fortbildungskursen herangezogen. 
Führen auch diese Maßnahmen zu keiner Verbesserung, ergehen auf Basis der 
Eingruppierung auch Entlassungen: 


„These [die Beschäftigten in der vierten Leistungskategorie - PF] are the 
people, who are not performing at all. For them, we have planned that we 
set them for failure. It is like, we say that: “We will invest in you, we have 
performance improvement plan.’ We give them opportunities, coaching 
etc. If the person is still not able to perform, then we have to say: ‘Ok, this 
is probably not the right place for that person.’ Not that he or she is bad, 
but maybe not to our standards.“ (SI7) 


Andersherum haben die Bewertungen allerdings natürlich auch positive Wirkun- 
gen für die gut bewerteten Beschäftigten. An die zweite Bewertung des Jahres 
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schließt sich ein weiterer Prozess an, in dem über Gehaltserhöhungen und Beför- 
derungen entschieden wird. In diesen Prozess gehen die beiden vorhergehenden 
Bewertungen der Beschäftigten ein. 

Grundsätzlich gibt es bei ServiceTec für jede Funktion im Unternehmen 
ein festgelegtes Gehaltsband, das ein bestimmtes Grundgehalt definiert. Dieses 
Grundgehalt wird anschließend um variable Bestandteile ergänzt. Dabei variiert 
der variable Anteil zwischen unterschiedlichen Funktionen im Unternehmen, 
grundsätzlich wächst er mit dem Aufstieg innerhalb ServiceTecs. So machen diese 
variablen Zahlungen auf der untersten Hierarchieebene (der Entwickler) einen 
geringeren Anteil aus als in den höheren Ebenen der Projektmanager oder gar des 
höheren Managements. Der variable Gehaltsbestandteil setzt sich aus den drei 
Komponenten Unternehmensgewinn, Gewinn der Abteilung und individueller 
Leistung zusammen. 


» loday every person in the organization has a variable component in his or 
her salary, which could vary from, say, one percent to 35% of the overall 
gross [Brutto - PF]. If 100 Rupees is a salary - at the lowest levels, it could 
be that one Rupee is ... are variable pay. At the highest levels it could be 30 
to 31 Rupees, 35 Rupees out of the hundred is variable, pay at risk. And 
what we did, was that, we said that, in India - it still differs from country 
to country, when I am talking, I am referring to India model to greatest 
extent, because that’s where most of the people are. And ... we said the 
compensation would be ... incentives would be, eh, at ... based on the, eh, 
in company performance, the performance of the unit, which he or she 
belongs, and the individual’s performance.“ (SI7) 


Sind die Gewinne des Unternehmens und der Business Unit Faktoren, die fiir 
jedes Jahr von der Unternehmensleitung festgesetzt werden, so wird die individu- 
elle Leistung durch genau jenen oben erwahnten jahrlichen Bewertungsprozess 
bestimmt. 

Die Hohe der variablen Zahlungen korreliert dabei positiv mit der Einteilung 
in Leistungskategorien. Jedoch wird bei ServiceTec darauf geachtet, dass die 
Beschäftigten in der ersten Kategorie überproportional entlohnt werden. Dies 
folgt folgender strategischer Zielsetzung: 


»Rather than being the best employer for all employees, we will be a 
better employer for better employees. So we started differentiating on 
performance. We said that: the best of employees, we would reward them 
with a much higher level, as compared to the average employee or the 
below-average employees.“ (SI7) 
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Diese überproportionale Steigerung der Gehälter in der höchsten Leistungsklas- 
se verstärkt den Anreiz für die Beschäftigten, möglichst hoch eingruppiert zu 
werden und steigert damit auch die interne Konkurrenz. 


„We set people in bands of their standards, that if you don’t perform, you 
know that, there will be a relative ranking and your peer could be rated 
above you. And he or she could earn a higher salary than what you are 
earning. And that brings in a sense of healthy competition amongst the 
employees as such.“ (SI7) 


Diese Konkurrenz wird noch dadurch gesteigert, dass das Zahlenverhältnis der in 
die vier Kategorien eingeteilten Beschäftigten vorher nach einem fixen Schlüssel 
festgelegt wird. Der genaue Schlüssel ist vertraulich, so dass darüber in den 
Interviews keine Informationen gewonnen werden konnten. Sicher ist aber, dass 
die Verhältnisse vorher festgelegt werden, wie ein Interviewpartner erläutert: 


„So at each band, we say that certain percentage of the people need to 
be performance band 1, certain percentage - in case of post-ranking - of 


performance band two, performance band three, and performance band 
four.“ (SI7) 


So wird selbst in Teams, deren Mitglieder sehr ähnliche Leistungen bringen, 
anhand kleiner Unterschiede differenziert. Diese inszenierte Konkurrenz unter 
den Entwicklern wird im nächsten Abschnitt noch ausführlicher Thema sein, 
da sie ein wesentliches Merkmal der Kooperationsbeziehungen bei Service Tec 
darstellt. 


5.3.3 Kooperationsbeziehungen 
Beziehungen innerhalb des indischen Entwicklungszentrums 


Das primäre Bezugsfeld der Entwickler in ihrer täglichen Arbeit ist das Modul, in 
das sie innerhalb ihres Projektteams eingeteilt wurden. Schon räumlich befinden 
sich die Entwickler in sehr engem Kontakt zu den anderen Kollegen des Moduls, 
Wie erwähnt, arbeiten sie in einem sogen. „Cubicle“, also einer quadratischen 
Anordnung von 4 Schreibtischen, die durch Trennwände vom Rest des Groß- 
raumbüros abgetrennt sind. Dabei sind diese Cubicles nicht gerade groß, so dass 
das gemeinsame Arbeiten darin mitunter recht konfliktreich sein kann, wie ein 
Entwickler schildert: 


„You have to learn to adjust with your team members and to work in a 
team environment. You sit in a cubicle with 4 people around you, so you 
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don’t have your personal space. Things like that.“ 

F: Are there conflicts about that, when you work in a cubicle? 

Yes, that’s what you have to learn, to avoid those conflicts. 

F: What are the conflicts about? 

It can be about somebody playing music on a system, it can be as small as 
that.“ (S120) 


Allerdings führt diese Nähe auch dazu, dass die Entwickler in permanentem 
Kontakt zueinander stehen und daher auch bei Problemen oder Unklarheiten in 
Bezug auf ihre Arbeitsaufgaben mit den anderen Entwicklern in ihrem Cubicle 
direkt und unkompliziert kooperieren, d.h. etwaige Probleme diskutieren und 
zu lösen versuchen: 


F: And would they work in groups? 

„Yah, they usually interact among themselves.“ [...] 

F: So everybody would have a single task, but they would interact? 

„Yah, like some people would be coding, some people would be testing. 
They will discuss among themselves if they find any issues. They keep on 
constantly discussing those issues.“ (SI14) 


Die Kooperation innerhalb der Module scheint dabei allerdings über eine gegensei- 
tige Hilfestellung bei Problemen nicht weit hinauszugehen. Wirklich gemeinsam 
wird auf der Ebene der Entwickler selten gearbeitet, wie eine Entwicklerin aus 
einem Wartungsprojekt überzeugend klarstellt: 


„No, two people working on the same defect means: one resource is wasted.“ 


(SI1) 


Aus den Ausführungen zur Aufgabenorganisation bei ServiceTec ließ sich bereits 
ersehen, dass Arbeit für die Entwickler in erster Linie Arbeit an individuell 
zugewiesenen Aufgaben ist: Die Entwickler bekommen vom Modul- oder Pro- 
jektleiter ihre Arbeitsaufgaben zugewiesen, und die Aufgaben sind dabei so 
gestaltet, dass sie von den einzelnen Entwicklern alleine erbracht werden können: 


„At the junior level the whole day is almost like working on something 
that is allocated to them.“ (SI14) 


Wenn es doch einmal vorkommt, dass zwei Entwickler in ihren Arbeitspaketen 
eine Überschneidung haben, kommt es eher zu Konflikten, wie ein Befragter aus 
seinem Projekt berichtet. Interessant ist bei der Schilderung dieses Entwicklers, 
dass eine solche Situation von ihm als besonders regelungswürdig wahrgenommen 
und sogar ein Eingreifen des Modulleiters gefordert wird: 
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„When 2 people are working on the same thing - at times it happens that 
both of them are adamant in their way of working. That’s where the team- 
work things come in, that is where the lead has to ... take control, I would 
say.“ (SI20) 


Teamwork in Bezug auf die tägliche Arbeit - in einem über gegenseitige Hilfe- 
stellung hinausgehenden Sinne - findet sich demnach bei den Entwicklern von 
ServiceTec selten. Vielmehr bestehen Modulen aus einer Reihe von „individual 
contributors“ (SI7), also von einzelnen Beschäftigten, die alle ihren klar defi- 
nierten und begrenzten Teil zur Gesamtleistung beitragen, diesen aber nicht 
gemeinsam erbringen. 


Diese „Kultur des Individualismus“ (Upadhya und Vasavi 2006) prägt, wie im 
Abschnitt über die Kontrollstruktur (Kapitel 5.3.2) gezeigt werden konnte, nicht 
ausschließlich die Art der Aufgabenorganisation im Unternehmen, sondern wird 
durch eine auf Messung und Bewertung individuell gezeigter Arbeitsleistung ab- 
zielende Kontrollstruktur unterstützt. Erklärtes Ziel des Bewertungssystems bei 
ServiceTec ist, die Entwickler um die besten Bewertungen und die damit verbun- 
denen positiven Sanktionen (Beförderungen, Gehaltssteigerungen) konkurrieren 
zu lassen. Offensichtlichster Ausdruck dieser Strategie sind, wie gezeigt wurde, 
die halbjährlich firmenintern veröffentlichten „Rankings“, also die Ranglisten 
der erreichten Bewertungen im Team, wodurch alle Beschäftigten in eine hierar- 
chische Beziehung gemäß ihrer Arbeitsleistung gebracht werden. 

Darüber hinaus finden sich bei ServiceTec eine ganze Reihe von Wettbewerben, 
in denen auf individueller Ebene um kleine symbolische Anerkennungen und 
Titel konkurriert wird, und womit die Mitarbeiter zu zusätzlichen Leistungen 
motiviert werden sollen. Der im Folgenden zitierte Manager hat z.B. mit einem 
Preis in Form eines Kinotickets für die beste Tagesleistung in Indien sehr positive 
Erfahrungen gemacht: 


„In India a ‘Kinoticket’ is a great motivating tool. Not because it’s a two 
Euro ‘Kinoticket’, it is because he feels it as a prize, that I got recognized 
for something. Right, I mean, he very well can afford the damn ticket, it’s 
not like five thousand Rupees or something, it’s more the ‘I am the boss for 
today, I won something’.“ (SD6) 


Dementsprechend entdeckt man bei einem Rundgang durch die Etagen mit den 
Cubicle-Komplexen bei ServiceTec eine bunte Mischung an kleinen Pokalen 
und Urkunden. Die Tatsache, dass diese stets stolz oben auf die Monitore oder 
Regalbretter gestellt werden, so dass sie über die Trennwände herausragen und 
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somit für die gesamte Etage sichtbar sind, zeigt die Relevanz, die diesen individu- 
ellen - teilweise aber auch auf Teamebene angesiedelten!? - Wettbewerben bei 
ServiceTec auch von den Beschäftigten beigemessen wird. 

Eine Beschäftigte schildert die Dynamik und die Stimmung, die unter den 
Entwicklern durch diese unterschiedlichen Maßnahmen zur Herstellung von 
Konkurrenzverhältnissen geschaffen wird: 


„I have many relatives and friends, who are staying in the US, who are 
living there in the US and, so. That sort, I feel, when they say about their 
work times there and how get to - that here, there is more competition 
here and, even if you want to finish your work in time and go home and 
spend time with your family and do something else - but others in the 
project, who are, like I said [lacht] earlier, who sit in office and work, work, 
because they get bored at home and they love to work more and more, they 
obviously spoil the total environment and, if a person is working more and 
your superior expects the same from you, and that would create a negative, 
eh, I mean, his own view of your doing or whatever. [...] And every time, 
there is a competition, there are more people getting into IT and everybody 
is trying to promote, everybody is, and people are obviously trying, doing 
much more than what is expected.“ (S113) 


Die Versuche von Seiten ServiceTecs, die Konkurrenz zwischen Entwicklern zu 
schiiren, fallt dabei durchaus auf fruchtbaren Boden, wie die Aussage der zitierten 
Entwicklerin andeutet. Ihre Schilderung der anderen Kollegen, die ihre Zeit im 
Biiro verbringen, weil sie sich zuhause langweilen wiirden, tauchte in der Tat hau- 
fig in den Interviews auf. Bei naherer Betrachtung ist diese Aussage auch gar nicht 
so überraschend. Wie im folgenden Abschnitt über die Rekrutierungsstrategie 
ServiceTecs noch ausgeführt werden wird, rekrutiert ServiceTec auf der Ebene 
der Entwickler vor allem sogen. „Fresher“, also junge Leute, die gerade die Univer- 
sitat verlassen haben. Dementsprechend jung sind die Entwickler bei Service Tec. 
Hinzu kommt, dass das Einzugsgebiet der IT-Unternehmen in Bangalore nicht 
auf regionale Arbeitskräfte begrenzt ist. Die großen IT-Städte, wie Bangalore, 
Mumbai, Delhi oder auch Hyderabad, sind das Ziel von Uniabsolventen aus ganz 
Indien, die in der Hoffnung auf einen Platz in der IT-Industrie in diese Städte 
ziehen. Viele der Entwickler, die schließlich bei Service Tec anfangen, sind dem- 
nach nicht nur sehr jung, sondern zudem häufig von ihrem bisherigen sozialen 
Umfeld weit entfernt. Von daher ist es nachvollziehbar, wenn diese Beschäftigten 
aussagen, dass sie nach Feierabend lieber im Büro bei ihren Kollegen bleiben, als 


18 So gibt es z.B. auch einen Wettbewerb um das „most spirited team“. 
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alleine in ihren Wohnungen zu sitzen. Dies gilt umso mehr, als die Büros Teil 
eines großen Campusgeländes sind, auf dem neben den Bürokomplexen auch 
sehr viele Freizeiteinrichtungen, wie Swimming-Pools, Billardhallen und diverse 
Restaurants den Beschäftigten zur freien Verfügung stehen (vgl. auch Kapitel 
5.3.4, Mayer-Ahuja 2011, Kap. 6.2.3). 


Doch sind die Kollegen im eigenen Modul nicht die einzige Bezugsgruppe der 
Entwickler. Schließlich bearbeitet ein Modul stets nur einen Unterbereich des Ge- 
samtprojektes. Dementsprechend kommt es auch vor, dass im Modul Probleme 
oder Unklarheiten auftauchen, die mit anderen Teilfunktionen oder -bereichen 
des Projektes in Verbindung stehen, und deren Lösung damit modulübergreifende 
Kooperation erfordert. 

Diese modul- oder in manchen Fällen auch projektübergreifende Kommuni- 
kation wird bei ServiceTec durch die Position des Modulleiters kanalisiert, wie 
ein Modulleiter auf die Frage nach den vorrangigen Kooperationspartnern seines 
Teams erläutert: 


„It’s mostly with my team members. But at times some problem comes 
in which goes across modules. In that case we have to interact with other 
modules also.“ 

F: Are you talking to the other module lead then or are your team members 
talking directly to the other team? 

„No, that communication part is done through me.“ (SI20) 


Dementsprechend findet eine modulübergreifende Kooperation zwischen den 
Entwicklern ebenfalls nur sehr selten statt, die Koordination der Arbeiten in den 
einzelnen Modulen ist vielmehr Sache der Modulleiter und der Projektleiter. 


Kooperationsbeziehungen zu Onsite-Teams und Kunden 


In eine ganz ähnliche Richtung geht auch die Gestaltung der Kooperationsbezie- 
hungen zum Onsite-Bereich. Schließlich befinden sich weitere für das Projekt 
wichtige Kooperationspartner außerhalb der indischen Entwicklungszentren vor 
Ort beim Kunden. Dabei handelt es sich zum einen natürlich um die Kunden 
selbst, zum anderen aber auch um die vor Ort beim Kunden arbeitenden Teams 
des Delivery-Bereiches von ServiceTec. 

Die Gestaltung der Beziehungen des Offshore-Teams zum Kunden schwankt 
bei Service Tec zwischen zwei Polen: Auf der einen Seite wird versucht, die Kom- 
munikation möglichst ausschließlich über den Onsite-Coordinator zu führen 
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und den Kontakt zum Kunden in dieser Person zu biindeln. Dies stellt bei Ser- 
viceTec den häufigsten Fall dar. Der Kontakt zum Kunden und die entsprechende 
Weitervermittlung zum Offshore-Team ist - wie bei der Darstellung des Geschäfts- 
modells ServiceTecs gezeigt wurde - auch der Schwerpunkt der Aktivitäten, die 
vom Projektteam Onsite durchgeführt werden. In den meisten Projekten kom- 
muniziert daher nur der Onsite Coordinator mit dem Kunden - die Entwickler, 
Module Leads und Projektmanager in den Offshore-Entwicklungszentren wen- 
den sich bei Klärungsbedarf zunächst an den Onsite Coordinator, der dann die 
entsprechenden Informationen einholt und weitergibt. Auf der anderen Seite 
kann durch dieses Vorgehen - gerade bei größeren Projekten - allerdings auch 
schnell eine Art „Flaschenhals“ entstehen, also ein Engpass in der Kommunikati- 
onsstruktur, der dann den Informationsfluss verlangsamt und behindert. Daher 
gibt es durchaus auch Projekte bei ServiceTec, bei denen die Offshore-Teams 
direkt mit dem Kunden kooperieren: 


„See, if the offshore people can talk directly to the clients, it makes our life 
very simple. If I have a problem today, can I pick up a phone and call my 
project manager, the clients’ person, say: “Yah, I’m having this problem. 
What shall we do?’ If I always have to go through one person, that becomes 
a bottle-neck. The relationships don’t build, the work gets suffered. I have 
a very clear tendency towards having more and more offshore people talk 
to the clients, very clear. I mean, that is what we would like to. In most of 
our other English-speaking clients we will do that.“ (SI17) 


Die zitierte Aussage weist jedoch bereits auf einige Probleme des direkten Kun- 
denkontaktes hin. Freut sich der oben zitierte Projektmanager dariiber, dass 
durch direkte Kommunikation auch die Beziehungen zwischen den Entwicklern 
und den Kunden verbessert wird, so sind diese Beziehungen bei ServiceTec stets 
unter kritischer Beobachtung, weil eine zu starke Gewöhnung der Kunden an 
einzelne Entwickler letztlich wieder die Personenunabhängigkeit der Projekte 
gefährdet. Von daher ist Kundenkontakt bei ServiceTec eine Gratwanderung. 
Direkter Kontakt beschleunigt zwar den Informationsfluss und verbessert die 
Kooperationsbeziehungen mit dem Kunden, stellt aber gleichzeitig die Fähigkeit 
in Frage, die Entwickler schnell zu ersetzen und zu verschieben, wenn der Kunde 
sich an einzelne Entwickler gewöhnt und auf eine Fortsetzung der Kooperation 
mit dieser Person besteht. Dies ist nach Aussagen der Projektmanager der Haupt- 
grund, warum der Kundenkontakt in den meisten der im Rahmen dieser Studie 
untersuchten Projekte schwerpunktmäßig über den Onsite-Coordinator und das 
Onsite-Team kanalisiert wird. 
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Ein weiteres Problem, das in der zitierten Aussage anklingt, ist die Sprache. So 
fühlen sich angeblich viele deutsche Kunden nicht wohl, wenn sie auf Englisch 
direkt mit den Offshore-Entwicklern kommunizieren müssen und bestehen 
auf deutschsprachigen Ansprechpartnern vor Ort. In diesen Fällen wird der 
Kontakt zum Kunden von den Onsite-Personen übernommen, die Deutsch 
sprechen. Eine direkte Kommunikation zwischen dem Kunden und den indischen 
Entwicklungszentren ist dann so gut wie ausgeschlossen, da es Offshore bisher 
nur sehr wenige Personen mit deutschen Sprachkompetenzen gibt!”. 


Darüber hinaus ist die Form des Kontakts zwischen Kunden und Offshore-Be- 
schäftigten von der Art des Projektes selber beeinflusst. So berichten Beschäftigte 
aus Maintenance-Projekten, dass sie häufig direkt mit den Kunden kommunizie- 
ren. 


„For a development project, yes. We try to make sure, that there is a single 
point of contact, that we minimize the communication gap between the 
client and the team.“ 

N: And in a maintenance project, that would be different? 

„In maintenance project also, if we have a person dedicatedly being located 
at the client’s location, at the client’s office, that probably he would be the 
single point of contact. But in a production support project, wherein we 
are handling around 15 to 20 applications, then we have to support a user 
base of 300, then we cannot have the single point of contact.“ (SI19) 


In diesen Fällen handelt es sich beim nötigen Kundenkontakt allerdings schwer- 
punktmäßig um Berichte über Defekte an laufenden Systemen, die in vielen 
Fällen durch Computersysteme strukturiert und in ihrer Form stark standardi- 
siert und formalisiert werden. Diese Reporting-Systeme ersetzen in vieler Hin- 
sicht persönliche Kommunikation, warum hier in einigen Fällen ganz auf einen 
Onsite-Koordinator und ein größeres Team vor Ort beim Kunden verzichtet 
werden kann. 


Schließlich unterscheiden sich auch die Kunden selbst in ihrem Wunsch und 
Bedürfnis nach direkter Kommunikation mit dem Offshore-Team: 


„There are clients, where we have faced situations, where they say that we 
do not want to talk to the offshore team. We would like our contacts to 
be limited to the onsite team. So all communication should come to that. 


19 Zum Zeitpunkt der Studie hatte sich Service Tec gerade dieses Problems angenommen und bot 
deutsche Sprachkurse für die Beschäftigten an. 
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We've had clients in Germany, France, lot of other places. So that becomes 
another reason, why we do not have too much of contacts. But again, 
I mean, it really depends very extremely from client to client scenario.“ 
(S17) 


Manche Kunden würden sich nach Angaben von Projektmanagern am liebsten 
direkt in die Arbeitsorganisation in den Entwicklungszentren einmischen, wo- 
hingegen andere damit zufrieden sind, onsite auf dieselben Leute zu treffen und 
mit diesen zu sprechen. 

So ist die konkrete Form, die die Kooperation zwischen Kunden und Offshore- 
Team annimmt, das Ergebnis eines komplexen Prozesses, in den mehrere Faktoren 
hineinwirken. 


Mit der Beziehung zum Kunden verändert sich auch die Beziehung zu den 
Onsite-Teilen des Projektes. Grundsätzlich wird ein ständiges, größeres Onsite- 
Team in dem Maße überflüssig, in dem der direkte Kontakt zwischen Offshore- 
Team und Kunden sich intensiviert.Wenn im Laufe eines Maintenance-Projektes 
die anfallenden Kooperationsnotwendigkeiten direkt zwischen den Offshore- 
Projektmanagern und den Kunden diskutiert werden können, wird das Onsite- 
Team personell verkleinert, was natürlich auch wieder zu Einsparungen führt. 
Aber selbst wenn während der Bearbeitungsphase ein Team vor Ort beim Kun- 
den bleibt, verliert dieses Onsite-Team durch den direkten Kundenkontakt des 
Offshore-Teams seine vermittelnde Rolle im Projektverlauf, und daher sinkt auch 
die Kooperationsintensität zwischen den beiden Teamteilen. 

Ganz anders stellt sich die Situation dar, wenn - wie in den meisten Fällen 
- der Kontakt zum Kunden ausschließlich oder schwerpunktmäßig über den 
Onsite-Coordinator und sein Team läuft. In diesem Falle hat das Onsite-Team 
eine sehr zentrale und erfolgskritische Funktion im Projektverlauf. Entsprechend 
stark wird darauf geachtet, die dadurch entstehende „bottleneck-Problematik“ 
nicht noch durch weitere Reglementierungen der Kommunikationsstruktur zu 
verschärfen. So ist der Kontakt zum Onsite-Koordinator und seinem Team bei 
ServiceTec sehr dezentral organisiert. Grundsätzlich sollen alle Modulleiter - 
und nach Rücksprache auch die Entwickler selbst - möglichst direkt mit dem 
Onsite-Koordinator kommunizieren und ihre Probleme oder Klärungsbedarfe 
mit diesem diskutieren. 


„The onsite coordinator talks to the offshore project manager and talks 
to the complete team as well at times. Because if the onsite coordinator 
just talks to the offshore project managers, that does create a long com- 
munication channel and what we foresee, is, there might be fissure on 
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the information. Some information might be missed. The onsite coordina- 
tor speaks to the complete team as well, whenever required. Whenever a 
team member needs a clarification we can approach the onsite coordinator 
directly.“ (SI17) 


5.3.4 Arbeitsmarktbeziehungen 
Rekrutierungsbemühungen 


Die Arbeitsmarktbeziehungen von ServiceTec sind auf der einen Seite von den 
hohen Wachstumsplänen des Unternehmens und auf der anderen Seite ganz 
wesentlich von der starken Konkurrenz auf dem indischen IT-Arbeitsmarkt 
geprägt. 

Betrachtet man die Entwicklung der Beschäftigtenzahlen von ServiceTec in 
den letzten Jahren, so lässt sich erahnen, welch große Anstrengungen die Firma 
unternommen haben muss, um von 10.000 Beschäftigten um die Jahrtausendwen- 
de auf über 90.000 Beschäftigte im Jahr 2008 zu wachsen. Der absolute Großteil 
des Beschäftigtenwachstums hat dabei in den Entwicklungszentren in Indien 
stattgefunden. 

ServiceTec rekrutiert vor allem Software-Entwickler, 70% der Einstellungen 
entfallen auf diese Stufe”. Im Gegensatz zu Beschäftigten, die gezielt für höhe- 
re Positionen gesucht werden und bei denen langjährige Berufserfahrung eine 
zentrale Voraussetzung für die Einstellung ist, werden auf der Entwicklerebene 
primär Berufseinsteiger direkt von der Universität eingestellt. 


„We realized that, if we were to grow faster, we had to hire people in, you 
know: batches, at entry level. And we had to train them and invest in them 
and grow them from within the company, to take on larger responsibilities. 
So as... There was a fundamental belief in this company, that we would 
invest and grow people from within and ... rather not do too much of 
hiring from outside. We’ll do hiring from outside at higher levels, but focus 
on getting people at the entry level.“ (SI7) 


Die Einstellungsbemühungen von ServiceTec nehmen dabei die Form von re- 
gelrechten Massenrekrutierungen an. Als dominantes Modell hat sich in den 
letzten Jahren dazu das sogen. „Campus-Recruitment“ durchgesetzt. „Campus- 
Recruitments“ bezeichnen spezielle Aktionstage an indischen Universitäten, an 


2 Die im Zusammenhang mit den Rekrutierungsbemühungen präsentierten Zahlenangaben sind - 
sofern nicht anders gekennzeichnet - alle einem Gespräch mit dem Head of Human Ressources 
(SI?) von ServiceTec entnommen. 
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denen das Lehrprogramm unterbrochen wird, um Unternehmen die Gelegenheit 
zu geben, sich den angehenden Absolventen zu prasentieren. Im Rahmen dieser 
Veranstaltung versucht ServiceTec bereits, Studierende an sich zu binden. Dazu 
können die Studierenden vor Ort einen Einstellungstest ablegen und im Falle 
des Bestehens ein Bewerbungsgespräch mit den anwesenden HR-Mitarbeitern 
führen. Bei Eignung für eine Einstellung bei ServiceTec erhalten die Studierenden 
gleich vor Ort eine Zusage von ServiceTec, die sie einlösen können, wenn sie ihr 
Studium erfolgreich beendet haben. Demenstprechend haben viele Studierende 
bereits einen Job sicher, bevor sie die Universität verlassen haben. 

Wie für alle IT-Dienstleister in Indien ist die primäre Zielgruppe für Rekrutie- 
rungen die Gruppe der Bachelor-Absolventen verschiedener Studienrichtungen 
im Bereich des Engineering und dort vor allem des Bereiches Computer Science 
oder Technology. Allerdings steht Service Tec in Indien weder mit seinen ehrgeizi- 
gen Wachstumsplänen noch mit seinem Fokus auf diese Zielgruppe alleine. Alle 
großen indischen IT-Dienstleister haben in den letzten Jahren ihre Beschäftig- 
tenzahlen ähnlich explosiv erhöht. Angeheizt wird diese Situation noch durch 
die vielen nach Indien drängenden multinationalen IT-Unternehmen, die auch 
beginnen, dort in großem Maßstab Belegschaften aufzubauen. 

Ein paar Zahlen mögen das Arbeitskräfteangebot in Indien und die Konkur- 
renz um dieses verdeutlichen: 235.000 Abgänger von indischen Universitäten 
im für IT-Firmen interessanten Segment des Engineering habe es im Jahr 2007 
gegeben?!, etwa die Hälfte davon (117.000) spezialisierten sich auf IT. Von diesen 
117.000 besuche ein Teil weiter die Universität, um einen höheren Abschluss, wie 
MBA o.ä. zu erwerben. Zusammen mit Personen, die ihre höheren Abschlüsse 
in dem Jahr absolviert haben, stehen der IT-Industrie ungefähr 108.000 Personen 
als Rekrutierungsmasse zur Verfügung. Von diesem Pool hatte allein Service Tec 
geplant, ca. 25.000 Personen einzustellen. 

Da diese Gruppe der Hochschulabsolventen die Zielgruppe von vielen IT- 
Firmen in Indien (vgl. z.B. auch Upadhya und Vasavi 2006, Athreye 2005a, Arora 
u. a. 2001) und entsprechend umkämpft ist, ist Service Tec, um seine ehrgeizigen 
Wachstumsziele zu erreichen, in den letzten Jahren dazu übergegangen, neben 
Absolventen I'T-spezifischer Studiengänge, auch Absolventen anderer Fachrich- 
tungen zu rekrutieren: 


„So we shifted to that model and at the same point of time we also realized 
that the education system in India - there are not enough computer science 


?! Auch hier wird wieder auf die Angaben des HR-Managers von ServiceTec rekurriert. Der 
indische Branchenverband NASSCOM veröffentlicht allerdings sehr ähnliche Zahlenangaben 
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graduates, who are graduating out on a year to year basis to meet the kind 
of growth targets we had set for ourselves.“ (SI7) 


In der Folge hat ServiceTec mittlerweile seine Bemühungen nicht nur auf sämtli- 
che Spielarten des Engineering, sondern auch auf gänzlich IT-ferne Studienfächer 
ausgeweitet. So rekrutiert ServiceTec mittlerweile auch Bachelor of Science and 
Arts: 


„So today we hire people from economics, history, literature, music and 
we ... last year we piloted the launch and we said that we put them to 
that 14 weeks training. And they did really well. So that gives us a belief 
that probably we can even train people with non-technology background, 
non-engineering backgrounds, and convert them into software engineers.“ 


(SI7) 


Mit dieser Ausweitung hat ServiceTec das mögliche Rekrutierungspotential stark 
ausgeweitet. Wie aus dem Zitat des HR-Managers bereits hervorgeht, ist eine der 
wichtigsten Voraussetzungen, die dieses Vorgehen ServiceTecs ermöglicht, das 
ServiceTec-eigene Trainingsprogramm. 


Trainingsmaßnahmen 


Das firmenspezifische Trainingsprogramm wird nicht nur den IT-fernen Uni- 
abgängern zuteil; eine festgelegte Phase des Trainings durchlaufen alle auf dem 
Einstiegslevel rekrutierten Beschäftigten bei Service Tec nach ihrer Einstellung. 
Allerdings richtet sich die Länge der Trainingsmaßnahme nach der Vorbildung 
der Beschäftigten, also konkret danach, ob diese ihren Abschluss in einem techni- 
knahen oder -fernen Studienfach gemacht haben. Wenn entsprechende technische 
Vorbildung vorhanden ist, dauert die Maßnahme drei Monate, bei fehlenden 
technischen Vorkenntnissen sind es dreieinhalb bis vier Monate. 

Der Inhalt dieser Trainingsmaßnahme ist in erster Linie technischer Natur. Die 
Neueingestellten bekommen ein intensives Training in von ServiceTec genutzten 
Technologien und Methodologien. Das betrifft zwar in weitaus stärkerem Maße 
die Personen, die aus technik-fernen Studiengängen zu ServiceTec stoßen, aber 
auch die Absolventen technischer Studiengänge und sogar Studierende der Com- 
puter Sciences werden in spezifischen Technologien und Methodologien geschult. 
Hintergrund dafür ist ein aus Sicht von ServiceTec unzureichendes Level der 
technischen Ausbildung an den indischen Universitäten (SI7). ServiceTec hat die 
Erfahrung gemacht, dass die Uniabsolventen nicht mit der für einen Einsatz in 
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der IT-Industrie nötigen Qualifikation die Uni verlassen”. Das zentrale Problem 
war nach Ansicht der HR-Manager, dass an der Uni veraltete Technologien und 
Methodologien gelehrt würden, die für die Projekte Service Tecs nur noch von 
geringem Nutzen sind”. Daher hat ServiceTec erhebliche Ressourcen in den 
Aufbau der eigenen Trainingsmaßnahmen gesteckt, in denen die Beschäftigten 
weiterqualifiziert werden. Von der Qualität ihrer Trainingsmaßnahmen ist Ser- 
viceTec sehr überzeugt. Angeblich sei ein indischer Uni-Absolvent (egal welcher 
Fachrichtung), der anschließend diese Schulung durchlaufen hat, ebenso qualifi- 
ziert, wie ein US-amerikanischer Student, der an einer amerikanischen Uni einen 
Bachelor in Computer Science macht, wie der zuständige HR-Manager erläutert: 


„So we said we’ll hire people, who had, from all disciplines of engineering, 
but we put them to the entry level training program. So once they complete 
that, they would be certified as trained software engineers. And we’ll hire an 
external evaluation audit done of our course. And we certify that anybody, 
who does 16 years of study in India, whoever goes through 16 years of 
education in India, and has those 14 weeks of training, initial training 
program - that person is equivalent to a BS [Bachelor of Computer Science 
- PF] kind of a qualification in the US.“ (SI) 


Und auch ein Projektmanager bestatigt dies: 


»And, when they are brought into the organization, they anyway undergo a 
very extensive four months of training, which has been eh, which has been 
eh, probably certified by one of the universities in USA as equivalent to the 
BS-degree in US. So, everyone goes through that extensive computer science 
training programme, which obviously gives them a very good insight of 
the computer science and on different languages.“ (S119) 


Die erwähnte Zertifizierung für die internen Trainingsmafßnahmen konnte lei- 
der im Rahmen dieser Studie nicht überprüft werden, jedoch zeigt bereits der 
Versuch, ein derartig ambitioniertes Niveau für die Trainingsmaßßnahmen zu er- 


2 Die HR-Manager von ServiceTec bestätigen damit die Befunde, die auch Unternehmensberatung 
McKinsey 2005 veröffentlicht hat Farrell, Kaka und Stärze 2005 

3 Interessant in dieser Hinsicht ist, dass dieses Problem vom zitierten HR-Manager auf einen 
Ausverkauf des Lehrpersonals an den Universitäten durch die IT-Industrie zurückgeführt wird. 
Angeblich hätten die qualifiziertesten Leute die Universitäten zugunsten der IT-Industrie ver- 
lassen und die verbleibenden Lehrkräfte würden sich nur in älteren Technologien auskennen, 
wodurch diese weiterhin die Lehrpläne dominierten (vgl. SI7). In gewisser Weise schafft die 
IT-Industrie sich in diesem Bereich also ihr eigenes Problem. 
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reichen, wie wichtig ServiceTec dieses Thema ist”*. Dementsprechend anspruchs- 
voll ist das Trainingsprogramm auch gestaltet, wie eine Entwicklerin aus eigener 
Erfahrung schildert: 


„There were some group discussions and there was kind of activities, after 
that it’s completely technical training, and every, say, four days, four to 
five days a subject, and after two days we’ll have this ... some dozen or 
twenty-five ... online test. So that carries some percent of the ... I don’t 
remember exactly, maybe 20 marks of the hundred for that subject. And 
after the course get’s over, after the four or five days of course, we’ll have 
a test. This finally, all these quiz marks and the test marks sums up to 
hundred. And we had to clear each and every subject. And finally, after 
that, after all the subjects get over, we'll have a project. They'll make us 
a group of 8 people, and they’ll ask us to do some project. They give one 
week time for that, and we have to develop it and execute - and make it 
executable. Then again we’ll have one, around one week time for the final 
exams. It [...] will have questions of all, I mean whole our training. [...] 
That we have to clear to come and take over a project or the work we start.“ 
F: Could you describe that exam? 

„It’s not that easy. You have to... I mean, every day you have to keep reading. 
So every third day you'll have quiz, or test, or exam. So ... classes and then 
in the evening, you have to go through it ... And there were like some 
model question papers and some old papers and, they helped, but... It’s not 
that you can just come and clear it off. It is: You have to study.“ (SI1) 


Für die Dauer der Maßnahme werden die Teilnehmer in einem speziellen Trai- 
ningszentrum einquartiert, wo sie wohnen und arbeiten (vgl. SI7). So stellt das 
Training eine sehr intensive Lern-Phase für die Beschäftigten dar. Wer das End- 
Examen nicht besteht, verlässt an diesem Punkt bereits das Unternehmen. Alle 
anderen werden vom Unternehmen für eine sechsmonatige Verpflichtungsphase 
übernommen. Innerhalb dieser sechs Monate können die Beschäftigten das Un- 
ternehmen nicht durch Kündigung verlassen. Erst nach diesen sechs Monaten 
werden sie unbefristet ins Unternehmen übernommen. 


Welche Technologien in dem Training vermittelt werden, welche Methodologien 
erlernt werden, hängt von dem von ServiceTec erwarteten Projektaufkommen 
ab. Die Wünsche der Beschäftigten werden dabei nach eigenen Angaben in der 
Regel nicht berücksichtigt: 


4 Der Hintergrund ist, dass Personen, die ein H1B Visum in die USA beantragen wollen, mindes- 
tens einen Bachelor oder gleichwertigen Abschluss nachweisen müssen (vgl. Mayer-Ahuja 2011, 
Kapitel 7.1.2) 
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„It is, there is no option for us to select, there was no option, because 
it is completely based on the requirements of the company, how many 
new projects they are expecting on different technologies and how many 
resources they would require for different streams, which the company is 
working on. [...] So, I was trained in Mainframes.“ (SI13) 


Eine andere Entwicklerin ergänzt: 


F: But there is a certain perception that somebody is especially lucky to be 
in one technology and not in the other? 

„Yah, means we ... there is a perception! But while choosing, the higher 
authority they don’t see all that. They put randomly the batch: ‘Ok, there’s 
requirement in mainframes and that batch is coming on that day’, they’ll 
say ‘Ok, we want it. We want them to be trained in mainframes.’ So that’s 
it“ (S12) 


Dabei ist der Schwerpunkt der Trainingsmaßnahme nicht notwendigerweise aus- 
schlaggebend dafür, welchen Projekten die Absolventen anschließend zugeteilt 
werden. Wieder folgt die Verteilung der Einsteiger auf die verschiedenen Projekte, 
Geschäftsbereiche und z.T. sogar Entwicklungszentren an verschiedenen Stand- 
orten, den zum jeweiligen Zeitpunkt des Einstiegs herrschenden Bedürfnissen 
des Unternehmens. Für die Beschäftigten bringt dieser Zustand einen großen 
Unsicherheitsfaktor ins Spiel: Zum Zeitpunkt der Bewerbung ist oft noch unklar, 
welche Projekte in der nächsten Zeit Bedarf an Beschäftigten haben. Entschieden 
wird dies am Ende der Trainingsmaßnahme, wie eine Entwicklerin schildert: 


„Once I joined ServiceTec, I got my training and all - in internet streams. 
Only after that we kind of come to know: ‘Ok, these kinds of projects will 
come in.’ As in we had induction programs, which told us the clients are 
banks, telekom companies, insurance companies, health care companies. 
So that was a basic idea we had got, but not exactly what kind of work 
would I be put into or something.“ (SI2) 


Bei dieser Verteilung auf die verschiedenen Projekte kommt es nach Angaben der 
Entwickler haufiger vor, dass das Training nicht zu den spateren Projekten passe: 


F: Would that be a common experience, that your training doesn’t fit into 
what you are doing afterwards? 

„Yes, it’s very frequent. Because it’s depending on the availability of the 
project.“ (S121) 


Die Absolventen werden also nach dem Einstiegstraining sehr flexibel und je 
nach Bedarf des Unternehmens auf die verschiedenen Projekte verteilt. 
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Allerdings bezieht sich die Flexibilität des Einsatzes nicht nur darauf, in welches 
Projekt die Absolventen gerufen werden, sondern auch der Einsatz in diesen 
Projekten ist zunächst flexibel. So werden alle Absolventen des initialen Trainings 
gleich behandelt, es wird z.B. nicht weiter zwischen Personen mit technologie- 
naher und -ferner Ausbildung unterschieden. Dies betrifft sowohl die Art der 
Projekte, in denen gearbeitet wird, als auch die Aufgaben, die den Entwicklern 
zugeteilt werden: 


„Finally, once the training is over we’re not like ... nobody is different. 
Everybody is the same. What they do is the same and whatever the apprai- 
sals or their ratings. So then it’s not ... Everything’s the same. There’s no 
difference. [...] I mean, if Pm in your project, you’ll not be knowing [...] 
what background I come from. I mean, if you talk to them personally, you 
come to know. But based on the work they do - no, you can’t. Everybody 
has to do the same work“. 


Das Ziel der Rekrutierungs- und (Einstiegs-) Trainingsbemühungen von Service- 
Tec auf der Ebene der Entwickler ist also die Herstellung einer großen Menge 
möglichst homogen qualifizierter Beschäftigter oder „Ressources“, wie sie im 
Jargon von ServiceTec stets genannt werden. Das Ziel sind Beschäftigte auf dem 
Einstiegslevel, die möglichst breit qualifiziert und damit sehr flexibel einsetzbar 
sind. 

Wie bereits im Unterkapitel zur Aufgabenorganisation bei ServiceTec geschil- 
dert wurde, bleibt dieser strategische Fokus für die Ebene der Entwickler auch 
während der Durchführung der Projekte erhalten. So konnte gezeigt werden, wie 
durch stete Rotation von Beschäftigten und Arbeitsaufgaben versucht wird, eine 
fachliche oder technologische Spezialisierung der Entwickler auf der Stufe der 
Entwickler möglichst zu verhindern, und diese Flexibilität des Einsatzes in den 
ersten Jahren zu erhalten. 

Diese Flexibilität befähigt ServiceTec, auf der einen Seite, mit Schwankungen 
im Geschäftsaufkommen und damit wechselndem Personalbedarf in unterschied- 
lichen Bereichen, und auf der anderen Seite, wie im folgenden erläutert werden 
soll, mit einer Besonderheit des indischen Arbeitsmarktes organisatorisch umzu- 
gehen: den hohen Fluktuationsraten. 
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Umgang mit Personalfluktuation 


Die schon erwähnte Konkurrenz (Kapitel 3.2) indischer und nach Indien drän- 
gender IT-Firmen um die relativ knapper werdenden” indischen IT-Fachkräfte 
erschwert Service Tec - wie gezeigt - nicht nur die Rekrutierung von Beschäf- 
tigten in einer für die ehrgeizigen Wachstumspläne ausreichenden Zahl und 
Qualität. Die starke Nachfrage nach IT-Fachkräften führt auch dazu, dass Be- 
schäftigte verschiedene Angebote abwägen und leicht zwischen verschiedenen 
Firmen wechseln können. 

ServiceTec gibt in seinem Geschäftsbericht für das Jahr 2007/08 eine durch- 
schnittliche Fluktuationsrate von knapp 14% für das Gesamtunternehmen an, 
womit es unterhalb des Branchenschnitts der letzten Jahre (vgl. Arora u. a. 2001, 
Upadhya und Vasavi 2006) liegt. Auch wenn von ServiceTec für diese Unter- 
suchung leider keine detaillierteren Informationen über die Fluktuationsraten 
zur Verfügung gestellt wurden, kann aus den Gesprächen mit den jeweiligen 
Projektteams geschlossen werden, dass sich die Fluktuation vor allem auf die 
Einstiegsebene und die Beschäftigten in den ersten Jahren nach Einstellung kon- 
zentriert und auf dieser Ebene daher wesentlich mehr als 14% beträgt. Dafür 
werden gleich eine Reihe von Gründen genannt: 

Zunächst gibt es viele Beschäftigte auf dem Einstiegslevel, die nach ihrem 
Bachelor die Universität verlassen haben, um erste Berufserfahrungen zu sam- 
meln, aber durchaus beabsichtigen, später noch weiter zu studieren, um z.B. 
ihren MBA zu erlangen. Diese Beschäftigten verweilen in der Regel 2-3 Jahre im 
Unternehmen und nehmen anschließend ihre Studien wieder auf (SI7). 

Ein weiterer Grund betrifft speziell die weiblichen Beschäftigten bei Service- 
Tec, die nach einer bestimmten Zeit häufig aus dem Unternehmen ausscheiden, 
weil sie entweder geheiratet haben und an den Wohn- und Arbeitsort ihres Man- 
nes ziehen”, oder nach Geburt der ersten Kinder die Firma verlassen. Nach den 
Erwartungen von ServiceTec verlassen viele der weiblichen Beschäftigten die 
Firma nach der neuralgischen Marke von ca. 5 Jahren Betriebszugehörigkeit, weil 
in diesen Zeitraum die meisten Hochzeiten, bzw. Geburten fallen: 


„Yah, of course, because, see, at the end of three years, that time we see the 
problem starts topping up. A lot of ladies start getting married or ... just 


5 In absoluten Zahlen steigt die Zahl der IT-Fachkräfte zwar, jedoch steigt die Nachfrage gegen- 
wärtig schneller als das Angebot, wodurch ein Fachkräftemangel entsteht (vgl. Kapitel 3.2). 

2° In dieser Hinsicht erweisen sich die indischen Geschlechterverhältnisse als schr starr und tradi- 
tionell, viele interviewte weibliche Beschäftigte klagten über die Aussicht, nach ihrer Heirat an 
den Ort ihres Mannes ziehen und dafür ihren Job bei Service Tec aufgeben zu müssen. 
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they could have got married and they plan a kid or something like that. But 
three years is when the problem starts. And after five years, is when the 
problem really hits, because: a second kid, or some people have got married 
at three years, want to have a kid after five years. So after five years is when 
it is a real problem for us to keep employees back.“ (SI7) 


Somit betrifft auch die speziell „weibliche“ Fluktuation vor allem die unteren 
Hierarchiestufen, also die Stufen der Entwickler und der Modulleiter (vgl. auch 
Mayer-Ahuja 2011, Kapitel 3.2.2 und 4.2.3). 

Und letztlich sind es auch gerade die jungen Uniabsolventen, die von den in 
Indien aktiven IT-Unternehmen besonders begehrt sind. Schließlich baut nicht 
nur ServiceTec seine Belegschaft gezielt auf den unteren Hierarchiestufen aus, 
sondern grundsätzlich haben alle Unternehmen gerade auf dieser Ebene im Zuge 
des weiteren Wachstums großen Bedarf an Arbeitskräften. 

Die aufgeführten Gründe führen demnach dazu, dass sich die höchsten Fluk- 
tuationsraten auf dem Einstiegslevel und in den ersten Jahren der Betriebszuge- 
hörigkeit zeigen. 


Auch wenn ServiceTec mit ca. 14% Fluktuation unterhalb des Branchenschnitts 
liegt, ist die Reduzierung und der organisatorische Umgang mit dieser Fluktuati- 
on ein dominierendes Thema. Wie in Kapitel 3.3 argumentiert, lassen sich zwei 
grobe Strategien identifizieren, mit denen Unternehmen versuchen, mit der Fluk- 
tuation umzugehen. Sie können demnach entweder versuchen, die Fluktuation 
zu reduzieren, indem auf Wünsche der Beschäftigten eingegangen wird und An- 
reize unterschiedlicher Art für die Beschäftigten geschaffen werden, längerfristig 
in der Firma zu bleiben. Oder man versucht, durch Standardisierung die Ar- 
beitsprozesse so weit wie möglich gegen Fluktuation zu „immunisieren“, indem 
die Abhängigkeit der Projekte von den Beschäftigten reduziert wird. Im selben 
Kapitel wurde bereits erläutert, dass sich diese Strategien keinesfalls gegenseitig 
ausschließen müssen, sondern vielmehr spezifische Mischungen dieser beiden 
Strategien in den untersuchten Unternehmen erwartet werden, die wesentlich 
vom jeweiligen Geschäftsmodell beeinflusst werden. 

So findet sich auch bei ServiceTec eine bestimmte Mischung aus Maßnahmen, 
mit denen Fluktuation auf der einen Seite gezielt reduziert und auf der anderen 
Seite „kanalisiert“ werden soll, indem die Projekte gegen hohe Fluktuation mög- 
lichst weit „immunisiert“ werden. Wenden wir uns im Folgenden zunächst den 
Maßnahmen zu, mit denen Fluktuation reduziert weden soll. 
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Das wichtigste Element dieser Bemühungen ist bei ServiceTec das Angebot 
von klaren und transparenten Karrierewegen innerhalb des Unternehmens. Wie 
bereits erwähnt, erwächst aus der starken Nachfrage auf dem indischen Arbeits- 
markt für die Beschäftigten die Möglichkeit, bei einem Unternehmen verwehrte 
Beförderungen auf dem „Umweg“ eines Firmenwechsels zu erhalten. Daher er- 
warten die Beschäftigten geradezu stetige Beförderungen als Voraussetzung eines 
Verbleibs in der Firma. Bleiben diese über einen längeren Zeitraum aus, steigere 
dies den Hang zum Firmenwechsel ganz erheblich (SD8). ServiceTec versucht 
diesem Problem zu begegnen, indem einerseits die Entscheidungen darüber, wer 
wann und warum befördert wird, möglichst offen kommuniziert werden, wie 
eine Vertreterin des Managements erläutert: 


„We try to be very open about the feedback that we give them. Because if 
they are not doing a good job, we ensure that we tell them. Because if we 
don’t tell them later on during promotions or we are doing appraisals, we 
give them a bad score then that should not come as a surprise. And many 
times people would leave because of that. Because they are not satisfied 
the way they have been, you know, their performance has been managed.“ 


(SI5) 


Im Abschnitt über die bei ServiceTec vorfindliche Form der Kontrollstruktur 
(Kapitel 5.3.2) wurde das Bewertungssystem bereits ausführlich beschrieben. Wie 
gezeigt, versucht Service Tec dabei mit den Maßstäben der Bewertung sehr offen 
umzugehen und zudem einem transparenten Bewertungsprozess zu folgen, der 
die Entwickler früh einbindet. Nach Aussage der zitierten Managerin geht dieses 
Verfahren also auch wesentlich darauf zurück, dass den Beschäftigten ein klares 
Bild ihrer Leistung im Unternehmen vermittelt werden soll, um „unangeneh- 
me Überraschungen“ an den neuralgischen Terminen der Beförderungen und 
Gehaltserhöhungen zu vermeiden, die angeblich häufig zu schneller Kündigung 
durch die Beschäftigten führen. So wird für jede Funktion im Unternehmen ein 
klares Profil bestimmt, welche Qualifikationen für diese Funktion vonnöten sind, 
und welche Voraussetzungen für eine Beförderung erfüllt sein müssen. 

Eine wichtige Voraussetzung für Beförderungen auf den unteren Hierarchie- 
stufen, also im wesentlichen von der Position des Entwicklers zu der des Modul- 
leiters””, ist z.B., dass die Person die Aufgaben des Modulleiters bereits für ein 
halbes Jahr ausgeübt haben muss, um auch formell befördert werden zu können. 
Zudem müssen für Beförderungen z.B. in eine Führungsposition entsprechende 


” Die Beförderungen von der Stufe der Projektmanager ins höhere Management laufen nur noch 
über individuelle Interviews. 
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Kommunikationsfähigkeiten belegt werden. Für die einer Rolle zugeordneten 
technischen Anforderungen gibt es ein unternehmensinternes Zertifizierungs- 
system, das bestimmte technische Qualifikationen belegen soll. Selbiges gibt es 
auch zum Erwerb von Kenntnissen in bestimmten Branchen. Durch diese klar 
kommunizierten Anforderungen für eine Beförderung wird für die Beschäftigten 
nach eigenen Angaben leicht absehbar, ob demnächst eine Beförderung für sie in 
Frage kommt oder nicht. 

Dazu trägt natürlich auch bei, dass nur die leistungsmäßig am höchsten be- 
werteten Beschäftigten für eine Beförderung in Frage kommen. Wie bereits im 
Zusammenhang mit der Kontrollstruktur (siehe Kapitel 5.3.2) geschildert, basiert 
eine mögliche Beförderung bei ServiceTec grundsätzlich auf einem halbyahrli- 
chen Bewertungszyklus durch die Vorgesetzten und dem nach der Bewertung 
stattfindenden Ranking-Prozess der Beschäftigten nach Leistungsgruppen. Daher 
können die Beschäftigten bereits anhand ihrer Bewertungen abschätzen, wie 
wahrscheinlich eine Beförderung für sie in der nächsten Zeit sein wird. 

Doch es ist nicht nur die Transparenz des Beförderungsprozesses, der helfen 
soll, die Fluktuationsraten gering zu halten. So war ServiceTec in den letzten 
Jahren auch in der guten Position, häufig und - wie sich später im Vergleich zur 
Produktfirma NovoProd zeigen wird - auch vergleichsweise schnell befördern zu 
können, weil durch das enorme Wachstum viele Stellen in Managementpositionen 
besetzt werden mussten. Auch wenn das Management bei ServiceTec stets großen 
Wert darauf legt, zu betonen, dass ausschließlich nach Leistung und betrieblicher 
Verfügbarkeit von Positionen befördert werde, bildet sich bei den Beschäftigten 
dadurch doch eine recht klare Vorstellung heraus, in welchem Zeitraum eine 
Beförderung erfolgen soll: 


„One important level, we have software engineers, like a person joins the 
company and gets time for 4 months in the company and then he becomes 
a software engineer. The typical career of a software engineer is from about 
.. up to 2.5, 3 years experience depending on the performance of a person. 
[...] He then moves on the next level, which is known as programmer 
analyst. The next step is the project manager, it’s about 5.5 to 6 years 
experience. Once it goes beyond that, than it is a senior project manager“ 
(SI6). 


Von daher steht trotz aller gegenläufiger Versuche des Managements für die Be- 
schäftigten auch eine klare zeitliche Erwartung hinsichtlich ihrer Beförderungen 
im Raum: 
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»But it is really not about time-bound promotion that you get. But as you 
rightly said, the folks who are doing very good, they do get a promotion 
every two years or two and a half years or three years. So people know that 
it is possible. And everybody wants to achieve that.“ (SI5) 


Dies gilt umso mehr, als eine längere Verweildauer auf einer Stufe bei ServiceTec 
auch als klarer Indikator für die Leistung der Entwickler behandelt wird, wie 
sich in folgender Aussage klar zeigt: 


„But then they would be the lowest performers in the organization, so then 
they work for four, five years also as software developers.“ (SI5) 


Es ist daher auch nicht verwunderlich, dass nach Angaben eines HR-Managers 
die Fluktuationsraten bei den unteren Leistungsgruppen sehr viel héher sind, 
als bei den höheren, da diese absehen könnten, dass ihr Aufstieg bei ServiceTec 
länger dauern wird und sich ein Firmenwechsel daher positiv auswirken könnte: 


„Then we see that our attrition rate varies according to performance bands. 
When we look at the ‘band 1’ or the highest performers, it’s much below 
the company average. When you look at the lowest band, ‘band 4’, it is 
probably at 50 to 60 percentage. So once people are put on those bands, 
they also realize, that they either have to improve that grades - they have to 
actually move out of the comfort zones, start learning, start performing, or 
they have to move out. And many times they chose to move out on their 
own.“ (SI7) 


Der Themenkomplex „Beförderungen“ ist dadurch bei ServiceTec alles andere als 
konfliktfrei. Auf der einen Seite versucht ServiceTec, mit der Frage der Beförde- 
rungen möglichst offen und für die Beschäftigten transparent umzugehen, klar zu 
kommunizieren, was für eine Beförderung nötig ist. Auf der anderen Seite hängt 
eine mögliche Beförderung natürlich nicht nur an der individuellen Leistung 
sondern auch an der Verfügbarkeit der jeweiligen Position im Unternehmen. 
Dieser letzte Punkt war durch das rasante Wachstum von ServiceTec bisher selten 
ein Problem, könnte aber bei Einbrüchen der Umsätze und des Geschäftsvolu- 
mens zukünftig durchaus zu einem Problem werden, wenn Service Tec nicht wie 
bisher jährlich in großem Maße befördern kann. Dann würde die nicht erfüllte 
Erwartungshaltung der Beschäftigten in Bezug auf ihre Karriere evtl. zu einem 
stärkeren Anstieg der Fluktuationsraten bei Service Tec führen, wie der folgende 
Projektmanager auf die Frage nach den schnellen Beförderungen bei Service Tec 
ausführt: 
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„Natürlich finde ich das nicht schön. Das ist kein natürlicher Schritt, das ist 
eigentlich sehr künstlich geworden, weil das Wachstum so rasant ist. Als 
ich vor 6 Jahren angefangen habe, waren wir 10.000 Mitarbeiter, heute sind 
wir 72.000 Mitarbeiter. Und sehr viele attrition rate, sehr viele wollen zu 
anderen Firmen gehen. Beförderungen muss es geben, um die Mitarbeiter 
noch zu halten. Und insgesamt, das große Fire wird größer und größer 
und das ist der Hauptgrund. Wenn es denn ein klassisches Geschäft wie 
Maschinenbau gewesen wäre - das kann man auch in Indien sehen, im 
Maschinenbau z.B. wird man nicht so schnell befördert.“ (SD8, die kursiv 
gesetzten Wörter waren sehr betont gesprochen - PF) 


Eng verknüpft mit schnellen und absehbaren Beförderungen ist die Frage des 
Gehalts und vor allem der Gehaltssteigerungen. Auch hier wird das System so 
gestaltet, dass es den längeren Verbleib im Betrieb unterstützt, bzw. attraktiv 
macht. 

Es ist nach Aussagen von Vertretern des höheren Managements explizit Strate- 
gie bei ServiceTec, nicht die besten Gehälter der Branche zu zahlen. Das Grund- 
gehalt auf der Einstiegsebene liegt daher nach Angaben von Managern und auch 
Entwicklern mit ca. 400 € brutto lediglich im Branchendurchschnitt. Das hat 
natürlich auf der einen Seite den Grund, dass man einfach nicht so hohe Kos- 
tensteigerungen haben möchte und daher versucht, die Gehaltssteigerungen der 
letzten Jahre nicht vollends mitzugehen. Auf der anderen Seite möchte man auch 
nicht in erster Linie diejenigen anziehen, die ausschließlich wegen des Geldes 
kämen, weil diese bei einem besseren Angebot erwartungsgemäß auch schnell 
wieder weg seien. 

Daraus lässt sich aber nicht folgern, dass bei Service Tec kein gutes Gehalt 
erlangt werden könne. Im Kapitel zur Kontrollstruktur (Kapitel 5.3.2) wurde 
bereits erläutert, dass alle Gehälter über das Grundgehalt hinaus variable, leis- 
tungsbezogene Anteile besitzen und diese Anteile sich überproportional erhöhen, 
sofern die Entwickler gute Bewertungen erhalten. Dieser Bestandteil sollte jedoch 
nicht überschätzt werden, da der Anteil der variablen Gehaltsbestandteile auf 
der Ebene der Entwickler noch vergleichsweise gering ist, sich aber mit Aufstieg 
stetig erhöht. Sollen Beschäftigte mit variablen Zulagen vor allem zu höherer 
Arbeitsleistung veranlasst werden, so zielt die Erhöhung der Grundgehälter eher 
darauf ab, Beschäftigte zu einem längeren Verbleib im Unternehmen zu motivie- 
ren. Nach Aussagen der Beschäftigten gehen die häufigen Beförderungen nämlich 
auch mit starken Steigerungen des Grundgehalts einher. Gaben Beschäftigte an, 
auf dem Einstiegsniveau umgerechnet ca. 400 € zu verdienen, so waren dies für 
die Rolle eines Projektmanagers - eine Position, die gut bewertete Beschäftigte 
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nach 5 Jahren erreicht haben können - bereits über 800 €. Es wird also ein 
relativ geringes Einstiegsgehalt mit hohen Steigerungsraten für die gut bewerte- 
ten Beschäftigten verknüpft. Auch hier gilt der bereits in Kapitel 5.3.2 zitierte 
Grundsatz: 


»Rather than being the best employer for all employees, we will be a better 
employer for better employees.“ (SI7) 


Für gut bewertete Beschäftigte bietet sich bei ServiceTec damit also die Mög- 
lichkeit, ihr Gehalt bei entsprechend längerem Verbleib in der Firma stark zu 
erhöhen. 

Eine weitere Maßnahme, mit der Fluktuation bei ServiceTec eingedämmt wer- 
den soll, besteht in befristeten Versetzungen von Beschäftigten aus den indischen 
Entwicklungszentren an den Ort des Kunden in den Onsite-Teil des Projektteams. 
Grundsätzlich werden die Teams vor Ort beim Kunden regelmäßig durchrotiert, 
um möglichst vielen Beschäftigten, die Möglichkeit zu geben, einmal vor Ort 
beim Kunden zu sein (vorausgesetzt, die Person erfüllt die Anforderungen an das 
Tätigkeitsprofil onsite, siehe Kapitel 5.2). 

Dieser Aufenthalt ist für die Beschäftigten aus zwei Gründen besonders at- 
traktiv: zum einen ist eine Beschäftigung vor Ort beim Kunden finanziell sehr 
interessant. Zwar behalten auch Personen, die für eine bestimmte Zeit beim 
Kunden arbeiten, formell ihren indischen Arbeitsvertrag, es gibt jedoch einen 
„Onsite-Bonus“, also einen Zuschlag, der das Gehalt auf das Niveau der vor Ort 
üblichen Gehälter anhebt. Aufgrund der Lohndifferenz zwischen Indien und 
Deutschland stellen diese Anhebungen für die indischen Beschäftigten eine er- 
hebliche Gehaltssteigerung dar. Für die Beschäftigten bietet ein Aufenthalt beim 
Kunden demnach nach eigenen Angaben die Möglichkeit, eine größere Summe 
zu sparen und damit nach der Rückkehr Investitionen in Indien vorzunehmen, 
z.B. ein eigenes Auto oder eine Wohnung zu kaufen: 


„We can send people on-site they have a higher potential of saving. Because 
you get paid as according the norms of that country and that’s much more 
than what you earn here. So we have policies about rotating people from 
offshore to onsite so that you give opportunities to all to earn something, 
to save a little bit more. The aspiration is still there to go on-site amongst 
the junior folks in the company.“ (SI5) 


Doch auch über den finanziellen Anreiz hinaus, sind die „Onsite-Postings“ für 
die Beschäftigten attraktiv, bieten sie doch die Möglichkeit, viel über die Region 
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und das Geschäftsumfeld des Kunden zu lernen. Diese Auslands- und Kunden- 
erfahrung - die bei Service Tec von den Beschäftigten stets „Exposure“ genannt 
wird - wird von den Beschäftigten als sehr karriereförderlich und spannend 
wahrgenommen. 

Diese „Onsite-Postings“ werden daher bei Service Tec sehr gezielt vergeben. 
Auch wenn das Management stets betont, dass eine Versetzung an den Ort des 
Kunden grundsätzlich für alle Beschäftigten gleichermaßen möglich sein soll 
und in der Tat die Mitglieder der Onsite-Teams häufig rotiert werden, stellt die 
Gewährung einer solchen Versetzung doch immer auch ein strategisches Mittel 
dar, um wechselwillige Beschäftigte vielleicht doch in der Firma zu halten, wie 
folgender Manager verrät: 


„Das ist eine Attraktion. Auf jeden Fall. Insbesondere, wenn jemand ankün- 
digt: ‚Ja, ich will die Firma verlassen‘. Dann wird sehr oft gefragt: ‚Okay, 
lohnt es sich, wenn wir dich nach onsite schicken, bringt das was‘. Und 
dann manche sagen: ‚Ja, das bringt mir schon was. Weil ich erstens mehr 
verdiene, und ... Eigentlich erstens mehr Erfahrung sammle und zweitens 
auch mehr verdiene‘. Das ist sehr beliebt. [...] Ich würde sagen, für 70% ist 
es schon eine Attraktion.“ (SD8) 


Neben der Etablierung von klaren Karrierewegen und attraktiven Versetzungen 
an den Ort des Kunden ist bei ServiceTec auch das Arbeitsumfeld als spezielle 
Attraktion für die Beschäftigten zu nennen. Auf die Frage nach den positiven 
Aspekten einer Beschäftigung bei ServiceTec nannten die meisten der Beschäftig- 
ten überraschenderweise das Arbeitsumfeld als einen der ersten und wichtigsten 
Punkte, wie auch beispielhaft der folgende Projektmanager: 


„Yes, I mean - one thing I liked about ServiceTec is .. I mean .. I feel like 
I am getting a very good environment to come here. You must have seen 
how the city of Bangalore is outside the ServiceTec world. If I’m coming 
here, I feel like I’m coming to the new world. I think that’s probably the 
inspiration I get.“ (SI6) 


Immerhin hat ServiceTec sehr großen Aufwand auf die Gestaltung der Büroge- 
bäude und des Betriebsgeländes verwendet. So finden sich auf diesem parkähnlich 
angelegten Betriebsgelände neben den sehr modernen und komfortablen Büroge- 
bauden diverse Freizeitangebote, wie Swimming-Pool Landschaften, Billardhallen 
und Golfplätze, die den Beschäftigten nach 17.00 Uhr kostenlos zur Verfügung 
stehen. Ebenso gibt es kostenlose Verpflegung in mehreren Kantinen mit abwechs- 
lungsreichem und umfassendem Angebot an Speisen und Getränken. Gegenüber 
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den Freizeitangeboten in Bangalore stellen die Anlagen ein sehr luxuriöses Am- 
biente dar und veranlassen demnach viele Beschäftigte, auch den Feierabend auf 
dem Firmengelände zu verbringen. 


„This is more than a place to work. [...] Typically we don’t call it as an 
office. We call it a campus, because it’s more than just sheer office buildings. 
You'll find the food courts, you'll find the endogen’s facilities, the medical 
centre, the bank, the typical food provision stores etc. So it’s, like: you 
can get all your work done over here, staying here. So you really don’t 
have to go out to aclub or something in the evening and all that stuff. So 
that creates an environment, where people can look to come back every 
morning, even, whatever traffic condition outside - people love to come 


back“ (SI7) 


Als letzter Punkt soll noch eine weitere Maßnahme zur Reduzierung von Perso- 
nalfluktuation erwähnt werden. Sie wirkt vor dem deutschen Erfahrungshinter- 
grund etwas seltsam, demonstriert aber eindrucksvoll, wie kreativ Service Tec im 
Kampf gegen die Fluktuation vorgeht und welch weitreichende Überlegungen zu 
diesem Thema angestellt werden. So gewährt ServiceTec sogen. „Dating Allowan- 
ces“. Dahinter verbirgt sich eine Kostenerstattung für persönliche Verabredungen 
zwischen männlichen und weiblichen Beschäftigten. So können sich Beschäftigte 
etwa die Kosten für Kinotickets von der Firma erstatten lassen. Damit sollen stra- 
tegisch unternehmensinterne Partnerschaften gefördert werden, da angenommen 
wird, dass es sich auf die Beschäftigungsstabilität positiv auswirkt, wenn beide 
Partner bei ServiceTec arbeiten. In die gleiche Richtung gehen auch finanziel- 
le Anreize in Form von Gehaltszuschlägen, wenn Beschäftigte ihre jeweiligen 


Partner oder Freunde zu einem Eintritt bei Service Tec bewegen*®. 


Gerade die zuletzt genannten Maßnahmen zur Vermeidung von Fluktuation 
zeigen sehr deutlich die Relevanz, die dieses Thema für ServiceTec besitzt. Umso 
erstaunlicher ist der Befund, dass von Seiten des Managements ein wesentlicher 
Punkt nicht angesprochen wird, mit dem Service Tec zu kämpfen hat, und der 
in den geführten Interviews auch mehrfach auftauchte: Wechsel der Firma auf- 
grund von Unzufriedenheit mit dem Inhalt und der Form der Arbeit. In ihrer 
Studie zu den Fluktuationsraten in der indischen IT-Industrie kommen Lacity, 
Rudramuniyaiah und Iyer (2008, S. 217f.) zu dem Schluss, dass die Suche nach 


238 Dieses sogen. „Buddy-Referral“, also das Anwerben von Freunden und Bekannten in die eigene 
Firma ist durchaus beliebt. Viele der im Rahmen dieser Studie interviewten Beschäftigten haben 
genau auf diesem Wege zu ServiceTec gefunden. 
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herausfordernden Arbeitsaufgaben bei den von ihnen interviewten Entwicklern 
sogar ein stärkeres Motiv ist, die Firma zu verlassen, als der Wunsch nach einem 
höheren Gehalt. 

Auch Upadhya und Vasavi (2006, S. 52ff.) betonen diesen Aspekt. Demnach 
haben gerade IT-Dienstleistungsunternehmen mit bestimmten Einschränkungen 
der Attraktivität ihrer Arbeitsaufgaben zu kämpfen, die aus dem Geschäftsmo- 
dell folgen. So müssen sie häufig mit relativ alten Technologien arbeiten, weil 
Kunden diese Technologien noch einsetzen. Bei ServiceTec z.B. muss ein Groß- 
teil der Beschäftigten noch mit Mainframes arbeiten, einer älteren und nach 
Aussagen der Entwickler auch umständlichen Technologie, die in ihrer Attrak- 
tivität längst nicht mit neueren Technologien mithalten kann. Zudem sind die 
Arbeiten auf Bereiche beschränkt, die Gegenstand von Offshore-Outsourcing 
sind. Wie beschrieben, sind dies meist unterstützende oder ergänzende Tätigkei- 
ten für den IT-Betrieb des Kunden. Auch konzentrieren sich in den Offshore- 
Entwicklungszentren zumeist die ausführenden und arbeitsintensiven Phasen 
der Softwareerstellung, die die Attraktivität der Aufgaben zusätzlich drücken. 
Hinzu kommt die typische Prozessorientierung der IT-Dienstleister und die dar- 
aus resultierende Form der Projektorganisation. All diese Aspekte führen nach 
den Ergebnissen von Upadhya und Vasavi (ebd.) dazu, dass viele Beschäftigte 
aus Unzufriedenheit mit ihren Arbeitsaufgaben nach einer gewissen Zeit die 
IT-Dienstleister auf der Suche nach attraktiveren Arbeitsaufgaben verlassen und 
ihr Glück bei anderen Firmen suchen. 

Dieses Thema wird bei ServiceTec jedoch kaum in Hinblick auf die Vermei- 
dung von Fluktuation behandelt. Zwar wird die Rotation der Beschäftigten 
zwischen Projekten und Arbeitsaufgaben von Seiten des Managements teilweise 
damit begründet, dass somit auch stetig wechselnde Aufgaben für die Entwick- 
ler entstünden, die Routine und Monotonie vorbeugen. Jedoch ist dies nach 
Darstellung der Entwickler wohl weniger wirkungsmächtig, da die Aufgaben so 
zugeschnitten sind, dass sie nach kurzer Einarbeitungszeit beherrscht werden 
können und sich schnell wieder Langeweile einstellt (vgl. auch ebd., S. 52). 

Die Gestaltung der Arbeitsprozesse folgt vielmehr dem Ziel der Immunisie- 
rung der Projekte gegen die negativen Wirkungen von Fluktuation: Man will 
die Projekte möglichst unabhängig von einzelnen Personen machen und die 
Fluktuation dadurch ihrer Risiken für den Geschäftserfolg so weit wie möglich 
berauben. Entscheidendes Mittel dazu ist die Prozessorientierung bei Service Tec 
mit ihren gezeigten Folgen, der starken Standardisierung und Formalisierung der 
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Arbeitsablaufe, mit denen die Abhangigkeit der Arbeitsablaufe von den einzelnen 
Entwicklern drastisch reduziert wurde. 

Zudem wurde bereits in Bezug auf die Aufgabenorganisation geschildert, dass 
dieses strategische Bemühen innerhalb der Projektteams organisatorisch noch 
dadurch unterstützt wird, dass Spezialisierungschancen der Beschäftigten durch 
stete Rotation der Teams und der Arbeitsaufgaben gezielt unterlaufen werden 
sollen und die Qualifizierungsbemühungen eher auf fachliche Breite statt Tiefe 
setzen (vgl. Kapitel 5.3.1). 

Diese Gestaltung der Arbeitsabläufe wird durch begleitende Maßnahmen er- 
gänzt, um die Unabhängigkeit der Projekte von einzelnen Entwicklern sicher- 
zustellen. So gibt es z.B. ein umfassendes „Backup-System“ für zentrale Rollen 
in Projekten. Dies bedeutet, dass für jede zentrale Rolle in einem Projekt eine 
Vertretung existiert, die permanent über alle Dinge, die die andere Person tut, auf 
dem Laufenden gehalten wird und den Fortgang des Projektes genau mitverfolgt. 
Formell kann diese Person währenddessen in einer anderen Funktion tätig sein. 
Im Notfall kann diese Person dann schneller die Tätigkeiten übernehmen, als 
wenn sie erst beim Fortgang des Kollegen eingearbeitet werden müsste: 


„Always there is a backup for everybody in the project. [...] Even our 
manager would have a backup, if he told, he has to leave, there would be 
one person, who will be knowing his work and who will be, who should 
be able to take care in his absence.“ (ST13) 


Dem „Problem“ individuell gewonnenen Erfahrungswissens - z.B. im Umgang 
mit Kunden, bestimmten Technologien usw. - das trotz aller Rotation im Projekt- 
verlauf stets auftritt, wird bei ServiceTec mit dem Aufbau eines systematischen 
Wissensmanagements begegnet. Dabei wird versucht, das Erfahrungswissen der 
Beschäftigten so weit wie möglich zu objektivieren und zu dokumentieren. So 
lasse sich die Gefahr, dass eine Person bei Verlassen des Projektes wichtiges 
Know-How mitnehme, reduzieren, wie folgender Projektmanager ausführt: 


„Ja, weil wir alles dokumentieren. [...] Ich würde sagen: 80% allen Wissens, 
das jetzt in den Köpfen ist, wird irgendwann mal irgendwie dokumentiert. 
Daher bleibt es im Team - die restlichen 20% sind immer Verlust.“ (SD8) 


Die Aussage dieses Interviewpartners, dass 80% des Wissens „irgendwann mal 
irgendwie“ dokumentiert werden, sollte nicht den Eindruck aufkommen lassen, 
dies sei eine unklare Sache und eher Wunschtraum des Managers als reale Praxis. 
Vielmehr ist die vage Äußerung Hinweis auf die Komplexität des Themas. So 
gibt es bei ServiceTec ganz unterschiedliche Ebenen, auf denen versucht wird, 
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das individuell gewonnene Wissen der Beschäftigten per Dokumentation zu 
objektivieren und übertragbar zu machen. 

Die wichtigste Einrichtung bei ServiceTec zu diesem Zweck ist eine Wissens- 
datenbank, in der jeder Beschäftigte Einträge erstellen kann, die dann von allen 
anderen Kollegen gelesen und ggf. ergänzt werden können. Thematisch sind den 
Einträgen dabei kaum Grenzen gesetzt; so können sie Informationen zu bestimm- 
ten Kunden oder zu bestimmen Technologien etc. enthalten. Diese Datenbank 
folgt damit grob der Idee eines Wikis, mit dem entscheidenden Unterschied, 
dass die Aktivitäten der Beschäftigten keinesfalls anonym sind, sondern ganz im 
Gegenteil gezielt protokolliert und analysiert werden, da das Engagement beim 
Aufbau und der Pflege der Datenbank auch gehaltsrelevant ist: 


„Und diese Dokumente werden auch .. es werden [...] Dokumente vorbe- 
reitet, die eher in generische Variante vorliegen. Also nicht spezifisch zu 
einer Person oder zu einem Modul oder zu einem Programm - und die 
dann sind ... stehen zur Verfügung für alle. Wir haben auch eigenes Portal 
[...]. Und da kann man diese [...] Dokumente dann auch uploaden. Und 
dann bekommt man sogenannte Currencies und so ... Punkte halt. Und 
je öfter das Dokument gelesen wird - das ist eigentlich unternehmensweit 
- desto mehr die Currencies werden dann teurer. Und dann am Ende des 
Quartals kann man die Currencies gegen Geld tauschen. [...] Ja, um halt 
einen Motivationsschub zu geben: ‚Ihr sollt mehr [Dokumente] schreiben, 
erstellen‘, und auch diejenigen, die das lesen und bewerten, bekommen 
auch bisschen, ... so dass auch mehr Leute eigentlich in diesen Lese-Zirkel 
auch einbezogen werden.“ (SD8) 


Mit der Einführung einer eigenen Währung für Dokumentationsleistungen wird 
also auch ein finanzieller Anreiz geschaffen, um die Beschäftigten zum freiwilligen 
Einstellen ihrer persönlichen Erfahrungen in dieses System zu motivieren. Diese 
Wissensdatenbank wird von den Beschäftigten anschließend genutzt, wenn z.B. 
Probleme mit bestimmten Kunden oder bestimmten Anwendungen auftauchen. 
In dieser Datenbank lassen sich Aufzeichnungen von anderen Projekten finden, 
die evtl. auch das Problem hatten, mit dem das aktuelle Projekt konfrontiert 
ist, und evtl. eine Lösung gefunden haben. Über die in der Dokumentation 
erwähnten Personen können so auch Ansprechpartner identifiziert werden. 
Entsprechende Dokumentationspflichten bestehen auch auf der Ebene des 
geschriebenen Programmcodes in Form von Kommentaren, die dem Code zur 
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Erläuterung beigefügt werden müssen, damit sich ein anderer Entwickler, der 
evtl. später damit arbeiten muss, schnell im Code zurechtfindet””. 

Die genannten Maßnahmen illustrieren den großen Aufwand, der bei Service- 
Tec betrieben wird, um die Abhängigkeit der Projekte und des Unternehmens 
von einzelnen Entwicklern zu minimieren. Diese Bemühungen sind bei Service- 
Tec sehr weit fortgeschritten, wie sich aus den Schilderungen der Beschäftigten 
entnehmen lässt. So berichten sowohl Projektmanager als auch Beschäftigte, dass 
es zumeist lediglich ca. 3 Wochen dauere, um einen das Projekt verlassenden 
Beschäftigten durch einen Nachrücker zu ersetzen. Gerade der Vergleich zum 
anderen in dieser Studie untersuchten Unternehmen NovoProd, in dem diese Zeit 
gewöhnlich mit sechs bis acht Monaten angegeben wird, zeigt drastisch, wie weit 
ServiceTec in seinen Bemühungen, die Arbeitsprozesse von den Beschäftigten 
unabhängig zu machen, fortgeschritten ist. 


Der spezifische Umgang ServiceTecs mit den für den indischen Standort typi- 
schen hohen Fluktuationsraten besteht also in einer sehr spezifischen Mischung 
aus Reduzierung und Kanalisierung von Fluktuation. Auffällig ist dabei, dass 
sich die Bemühungen, die Fluktuation zu reduzieren wesentlich auf den betrieb- 
lichen Rahmen richten: Anreize für die Beschäftigten werden v.a. in Bezug auf 
Karriereverlauf und Vergütung, attraktive Arbeitsplatzwechsel und das Arbeit- 
sumfeld geschaffen. Der Inhalt der Arbeit, und damit auch die konkrete Form 
der Aufgabenorganisation bleibt jedoch von diesem Bemühungen weitgehend 
unangetastet. Dieser Bereich wird vielmehr von der strategischen Zielsetzung 
dominiert, die Abhängigkeit von den Entwicklern im Arbeitsprozess soweit 
wie möglich zu reduzieren, und die Projekte damit gegen Personalfluktuation 
möglichst weitreichend zu immunisieren. 


® Dies mag auf den ersten Blick banal erscheinen, aber indische Entwickler klagen häufig über 
fehlende Kommentare im Programmcode, wenn sie in den Systemen des Kunden arbeiten 
müssen. 


164 Fallstudie ServiceTec 


5.4 Zusammenfassung und Bewertung der bei 
ServiceTec verfolgten Kontrollstrategie 


Als Anbieter von Offshore-Outsourcing Dienstleistungen verfolgt Service Tec 
ein Geschäftsmodell, dass dem der Literatur entnommenen Leitbild des „Global- 
Delivery-Models“ in fast allen Punkten entspricht. So findet sich bei Service Tec 
die typische Trennung der Arbeitsabläufe in einen kundennahen „Onsite“-Bereich 
und einen indischen „Offshore“-Bereich (hier: in Indien). Mit der räumlichen 
Trennung geht eine Arbeitsteilung einher, welche die planenden und konzep- 
tionellen, sowie die eher kommunikationsintensiven Tätigkeiten in den Onsite- 
Teams konzentriert, wohingegen die eher arbeitsintensiven und ausführenden 
Tätigkeiten auf die Teams im indischen Entwicklungszentrum entfallen. Diese 
Trennung begründet auch einen wesentlichen Unterschied in der Komplexität 
der am jeweiligen Standort ausgeführten Arbeitspakete. 

Zudem stellt die für das „Global-Delivery-Model“ für essentiell erachtete Pro- 
zessorientierung auch bei ServiceTec ein zentrales Merkmal der Arbeitsorganisati- 
on und -kontrolle dar. Betrachtet man die strategische Ausrichtung ServiceTecs in 
Bezug auf die Kontrolle der Arbeitsprozesse im indischen Entwicklungszentrum, 
so drängt sich der Begriff der „Software-Factory“ geradezu auf. Nach eigenen 
Aussagen versucht ServiceTec die „Industrialisierung“ der Arbeitsprozesse intern 
möglichst weitreichend umzusetzen und grenzt sich gezielt von einem Bild der 
Softwareentwicklung als einer kreativen und auf die Selbstorganisationsfähig- 
keiten der Entwickler angewiesenen Art von Arbeit ab. Statt dessen wird bei 
ServiceTec stets die umfassende Durchdringung der Arbeitsprozesse mithilfe 
standardisierter Prozessmodelle betont. Dementsprechend restriktiv sind auch 
die im indischen Entwicklungszentrum implementierten Kontrollstrategien. 


Wie sich bei der Analyse der Aufgabenorganisation gezeigt hat, prägen die Prozess- 
modelle ganz wesentlich die Art und Weise, in der bei ServiceTec versucht wird, 
die Gesamtleistung in einzelne Arbeitspakete zu zergliedern. Für jede von Ser- 
viceTec angebotene Art von Dienstleistung existiert eine Prozessbeschreibung, in 
der die nötigen Arbeitsschritte zur Erbringung jener Leistung definiert sind. Auf 
Basis dieser Ablaufvorgaben entwickeln die jeweiligen Projektverantwortlichen 
anschließend ihre detaillierten Projektpläne, die bereits die nötigen Arbeitspa- 
kete ausweisen, die anschließend auf die Beschäftigten des Teams - stets nur 
als „Ressourcen“ bezeichnet - verteilt werden. Service Tec hat großen Aufwand 
betrieben, diese Vorgaben, die sich aus den Ablaufbeschreibungen der Prozess- 
modelle ergeben, durch ein umfangreiches Set an weiteren Normenkatalogen, 
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wie z.B. Coding-Guidelines und detaillierten Checklisten für jeden Arbeitsschritt 
zu ergänzen, um die Komplexität und (damit zusammenhängend) die zeitliche 
Länge der Arbeitsaufgaben möglichst weit zu reduzieren. 

Das Zusammenspiel dieser Maßnahmen führt dazu, dass sich bei Service Tec 
eine extreme Arbeitsteilung mit sehr kurztaktigen und stark vorspezifizierten 
Arbeitsaufgaben findet. Nach Angaben der Gesprächspartner werden Arbeits- 
pakete angestrebt, die in einem Zeitrahmen von 2-8 Stunden bearbeitet werden 
können. Zwar wechseln die Arbeitspakete sowohl im Laufe des Projektablaufs, 
als auch dadurch, dass die in einer Phase des Projektes anfallenden Aufgaben 
rotierend vergeben werden, jedoch kann diese Abwechslung den monotonen 
und routinisierten Charakter der Arbeitsaufgaben nicht überdecken, der von den 
Beschäftigten ganz eindeutig zum Ausdruck gebracht wird. 

Vielmehr konnte gezeigt werden, dass die stete Rotation der Beschäftigten 
zwischen Arbeitsaufgaben und Projektteams, vor allem der Vermeidung von 
fachlicher Spezialisierung dient. Strategisches Ziel ServiceTecs ist es, die Projekte 
stets „process-depending and not people-depending“ zu halten. Ein Zuschnitt 
der Arbeitsaufgaben, deren Erledigung keine lange Einarbeitungszeit und kei- 
ne tiefen, über die technische Realisierung hinausgehenden, fachlichen Kennt- 
nisse erfordert, bietet Service Tec damit die Möglichkeit, die Beschäftigten auf 
Entwickler-Ebene sehr flexibel einzusetzen. Einerseits kann damit auf unregelmä- 
Biges Geschäftsaufkommen reagiert werden, indem Projekte personell schnell 
auf- und abgebaut werden können. Andererseits wird damit auch die Gefahr, die 
von den hohen Fluktuationsraten ausgeht, reduziert, indem Beschäftigte, die das 
Unternehmen verlassen, schnell durch andere Entwickler ersetzt werden können. 


So feingliederig die Arbeitsteilung bei ServiceTec ist, so detailliert und eng ist 
auch die Form der Kontrollstruktur. Die mit den Prozessvorgaben verknüpften 
Vorgaben zur Bearbeitung der Arbeitspakete fungieren dabei als zentrales Mittel 
der Anleitung und Anweisung der Entwickler. Bei Unklarheiten und Problemen 
stehen mit den jeweiligen Modulleitern darüber hinaus entsprechend weisungs- 
befugte und -befähigte Vorgesetzte bereit, die schon aufgrund der räumlichen 
Anordnung der Arbeitsplätze in einem gemeinsamen Cubicle stets präsent und 
ansprechbar sind. 

Auch für die Überwachung der Arbeitsabläufe ist die genannte Präsenz der 
Modulleiter wichtig, sind sie doch stets in der Lage, etwaige Probleme und Ver- 
zögerungen im Ablauf zu erkennen. Allerdings verlässt sich ServiceTec nicht 
ausschließlich auf diese persönliche Form der Überwachung, sondern hat zudem 
ein sehr detailliertes Computersystem implementiert, das neben der computerge- 
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stützten Zuweisung der Arbeitsaufgaben an die Entwickler auch die Funktion 
übernimmt, den Bearbeitungsvorgang für das Management transparent zu ma- 
chen, weil jeder Beschäftigte - nach Angaben der Beschäftigten auf Minutenbasis 
- seinen Arbeitstag und den Fortschritt der Aufgabenbearbeitung dokumentiert. 
So besteht auch unabhängig vom direkten Kontakt der Entwickler zu ihren Mo- 
dulleitern für die Projektmanager stets die Möglichkeit, sich über den Fortschritt 
der Projekte zu informieren. Der Rhythmus, in dem Manager sich über die Fort- 
schritte des Projektablaufes informieren, ist neben den strategischen Erwägungen 
ServiceTecs auch wieder von den Anforderungen der Kunden abhängig. Diese 
unterscheiden sich in der Intensität, mit der sie Fortschrittsberichte von Service- 
Tec einfordern. Häufig ist jedoch der vom Kunden geforderte Takt noch kürzer, 
als der von ServiceTec angestrebte. Auch an diesem Punkt wirkt sich also der 
Kundenkontakt wesentlich auf die Form der Arbeitskontrolle aus. 

Die enge Überwachung der Arbeitsprozesse auf individueller Ebene ermöglicht 
es ServiceTec schließlich auch, die individuell verausgabte Arbeitsleistung sehr 
detailliert zu „messen“. Zwar beruht der Prozess der Beurteilung von Arbeitsleis- 
tung auf Zielvereinbarungsgesprächen zwischen Management und Beschäftigten, 
doch zeigt sich bei näherer Betrachtung, dass es in erster Linie darum geht, die 
Beschäftigten mit recht fixen Anforderungen von Seiten des Unternehmens hin- 
sichtlich der Geschwindigkeit und Qualität der Arbeitsleistung zu konfrontieren. 
Die implementierten Systeme zur Messung von Arbeitszeit und zur Behebung 
von Programmierfehlern stellen dabei wichtige Instrumente dar, mit denen die 
individuelle Arbeitsleistung vom Management umfangreich erhoben und vor 
dem Hintergrund der explizierten Anforderungen beurteilt werden kann. 

ServiceTec betont dabei stets die individuellen Anteile der Entwickler am 
Teamerfolg. Gemäß der Formel der „individual contributors“ wird versucht, 
die Beschäftigten leistungsmäßig stark zu differenzieren. Deutlichster Hinweis 
darauf ist der Umstand, dass alle Beschäftigten eines Teams im Anschluss an den 
individuellen Bewertungsprozess zusätzlich noch einmal „gerankt“ werden, d.h. 
in eine hierarchische Reihenfolge in Bezug auf ihre individuelle Arbeitsleistung 
gebracht werden. Zudem ist die Verteilung der Beschäftigten auf die verfügbaren 4 
Leistungsgruppen vorab festgelegt, wodurch schon vor der Individual-Bewertung 
feststeht, wieviel Prozent der Beschäftigten in den verschiedenen Leistungsgrup- 
pen sein müssen. Auf diese Weise können auch kleine Differenzen hinsichtlich der 
Arbeitsleistung sehr gravierende Folgen haben: Da das Ergebnis des Bewertungs- 
prozesses die Höhe des individuell ausgezahlten Gehaltsbonus determiniert und 
der Zusammenhang zwischen Zielerreichung und Bonuszahlungen von Service- 
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Tec bewusst überproportional gestaltet wird, ist die Bewertung für Beschäftigte 
bei Service Tec auch finanziell von enormer Wichtigkeit. Mit diesem System der 
Leistungsbewertung wird eine interne Konkurrenz um die besten Bewertungen 
geschürt, die noch durch symbolische Wettbewerbe und Titel innerhalb der 
Teams verstärkt wird. 


Dementsprechend findet sich auf der Ebene der Projektteams auch eher eine Zahl 
von „individual contributors“ als wirklich kooperierende Teams. Arbeit auf der 
Ebene der Entwickler ist in erster Linie Arbeit an individuell zugewiesenen Ar- 
beitsaufgaben. Wenn Kooperation mit anderen Teams oder gar mit Beschäftigten 
des Kunden nötig ist, so ist ServiceTec bestrebt, diesen Kontakt - sofern möglich 
- über die Modul- und Projektleiter zu kanalisieren. 


Betrachtet man die Arbeitsmarktbeziehungen ServiceTecs, so fällt auf, welch 
großen Einfluss diese auf die von ServiceTec verfolgte Kontrollstrategie haben 
und wie viele der bereits erwähnten Aktivitäten zur Arbeitsorganisation und 
-kontrolle auch strategische Überlegungen zum Umgang mit der spezifischen 
Arbeitsmarktsituation reflektieren. 

Aufgrund der ehrgeizigen Wachstumspläne und dem daraus folgenden großen 
Personalbedarf ist Service Tec von dem am indischen Standort zunehmend auf- 
scheinenden Fachkräftemangel in seinen Rekrutierungsbemühungen stark be- 
troffen. Um dennoch in der beabsichtigten Geschwindigkeit zu wachsen, ist 
ServiceTec dazu übergegangen, neben der traditionellen Gruppe der Engineer- 
ing-Absolventen zunehmend auch neue Zielgruppen für die Rekrutierung zu 
erschließen. Voraussetzungen dafür schaffen die Trainingseinrichtungen Service- 
Tecs, in die in den letzten Jahren erhebliche Ressourcen investiert wurden, um 
das Qualifikationsniveau der neu rekrutierten Beschäftigten durch eine intensi- 
ve Einführungsphase sicherzustellen. In gewisser Hinsicht bildet die Form der 
Aufgabenorganisation auch die Voraussetzung dafür, dass solcherart geschulte 
Beschäftigte schnell produktiv in den Projekten mitarbeiten können, da längere 
Einarbeitungszeiten aufgrund des Charakters der Arbeitsaufgaben nicht nötig 
sind. 

Zudem stellt die strikte Prozessorientierung und die damit einhergehende 
Standardisierung und Formalisierung der Arbeitsabläufe die Grundlage für den 
speziellen Umgang Service Tecs mit den für den indischen Standort charakteristi- 
schen Fluktuationsraten dar. Mit knapp 14% liegt Servicetec zwar unterhalb des 
Branchenschnitts, doch trotzdem ist dieser Aspekt in allen Interviews präsent 
und wird sehr ernst genommen. 
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Es konnte gezeigt werden, dass der Umgang ServiceTecs mit den hohen Fluk- 
tuationsraten auf der einen Seite darin besteht, die Arbeitsprozesse gegen Fluktua- 
tion (durch Standardisierung und Formalisierung der Arbeitsabläufe) möglichst 
weitgehend zu immunisieren. Unterstützt werden diese Bemühungen durch In- 
itiativen im Bereich des Wissensmanagements, die darauf abzielen, (auch unter 
Angebot finanzieller Anreize) Beschäftigte dazu zu veranlassen, individuelles 
Erfahrungswissen zu dokumentieren und mit ihren Kollegen zu teilen, was 
wiederum die Abhängigkeit der Projekte von den einzelnen Beschäftigten redu- 
ziert. Zudem existiert ein ausgefeiltes Backup-System, das die Übernahme einer 
Position durch einen Nachfolger noch einmal beschleunigt. Zwar führt diese 
Standardisierung und Formalisierung, wie gezeigt werden konnte, zu geringer 
Jobzufriedenheit der Beschäftigten und fördert damit seinerseits die Fluktuation, 
weil viele Beschäftigte auf der Suche nach attraktiveren Jobs die Firma verlassen, 
doch ServiceTec ist gegenwärtig nach Angaben des höheren Managements noch 
in der Lage, diese Fluktuation in den Arbeitsprozessen zu verkraften. 

Ein Grund, warum die Fluktuationsrate bei ServiceTec trotz der geringen 
Jobzufriedenheit der Beschäftigten mit 14% noch unterhalb des Branchendurch- 
schnitts liegt, könnte sein, dass Service Tec zwar im Bereich der Arbeitsorganisa- 
tion auf eine möglichst weitreichende Immunisierung gegen Fluktuation setzt, 
sich im Bereich der betrieblichen Rahmenbedingungen jedoch stark bemüht, 
die Beschäftigten durch positive Anreize an die Firma zu binden und damit die 
Fluktuationsraten zu reduzieren. Als zentrale Elemente dieses Ansatzes konnten 
die Gewährung von schnellen und vor allem berechenbaren Karrierewegen, die 
damit zusammenhängenden Gehaltssteigerungen und die attraktive Möglichkeit, 
für eine Zeit vor Ort beim Kunden zu arbeiten, herausgearbeitet werden. Auch 
die luxuriöse Arbeitsumgebung auf dem Unternehmenscampus stellt für die 
Beschäftigten eine Attraktion dar, dauerhaft bei ServiceTec zu bleiben. 


Demnach geht bei ServiceTec die Internationalisierung der Leistungserstellungs- 
prozesse mit stark industrialisierten Arbeitsabläufen einher. Dies betrifft sowohl 
die standortübergreifende Kooperation als auch die Arbeitsabläufe im indischen 
Entwicklungszentrum. Die Standardisierung und Formalisierung führt dort 
zu extrem restriktiven Formen der Arbeitsprozesskontrolle durch das Mana- 
gement. Als Grund für diese strategische Ausrichtung konnte zum einen das 
spezifische Geschäftsmodell Service Tecs als Anbieter von Offshore-Outsourcing 
Dienstleistungen herausgearbeitet werden. Immerhin wirkt sich die dafür ty- 
pische Beziehung zu Kunden stark auf die Form aus, in der ServiceTec seine 
Arbeitsabläufe intern gestaltet. So konnte die extreme Prozessorientierung und 
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die Notwendigkeit, den Projektablauf stets eng und feingliedrig zu überwachen, 
wesentlich auf Ansprüche der Kundenunternehmen zurückgeführt werden. Zum 
anderen zeigt sich jedoch, dass viele Chrarakteristika der Aufgabenorganisation 
und -kontrolle bei ServiceTec auch Reaktionen auf die spezifischen Bedingungen 
am indischen Standort sind. So schafft die starke Standardisierung und Forma- 
lisierung der Arbeitsprozesse, die das Geschäftsmodell erfordert, gleichzeitig 
die Möglichkeit, auch gegenwärtig noch ehrgeizige Wachstumspläne am indi- 
schen Standort zu realisieren und gleichzeitig mit erhöhten Fluktuationsraten 
organisatorisch umzugehen. 


Die Intensität, mit der bei ServiceTec die „Industrialisierung“ der Leistungserstel- 
lungsprozesse und der internen Arbeitsabläufe betrieben wird, erklärt sich daher 
daraus, dass in diesem Fall das Geschäftsmodell eine starke Standardisierung und 
Formalisierung der Arbeitsprozesse erfordert, und dieses Vorgehen gleichzeitig 
eine Möglichkeit bietet, erfolgreich auf dem indischen Arbeitsmarkt zu agieren 
und die hohen Fluktuationsraten organisatorisch zu bearbeiten, sich die beiden 
Aspekte also gegenseitig in ihrer Wirkung verstärken. Das Zusammenwirken 
zwischen verfolgtem Geschäftsmodell und den spezifischen Bedingungen am indi- 
schen Standort ist allerdings nicht immer so harmonisch. Dies wird die folgende 
Fallstudie des deutschen Standardsoftwareherstellers NovoProd zeigen. 


6 „Struggle for Ownership“ - 
Arbeit und Kontrolle bei der 


deutschen Produktfirma NovoProd 


Steht der Fall ServiceTec für einen Reorganisationsmodus von Arbeit, der eine 
starke Standardisierung und Formalisierung der Arbeitsprozesse, sowie eine 
daraus folgende, extrem restriktive Form der Arbeitskontrolle beinhaltet, so stellt 
NovoProd einen gänzlich anders gelagerten Fall dar. Einer zu einem hohen Grad 
international verteilten Entwicklung von Softwareprodukten entspricht hier 
keine vergleichbare Standardisierung und Formalisierung der Arbeitsprozesse, 
wie dies bei ServiceTec zu beobachten war. Vielmehr finden sich im indischen 
Entwicklungszentrum von NovoProd viele Formen permissiver Kontrolle, die 
mit IT-Arbeit gewöhnlich assoziiert werden. 

Dieser deutliche Unterschied zu ServiceTec - so mein in diesem Abschnitt 
empirisch zu belegendes Argument - ist vor allem dem speziellen Internationali- 
sierungsweg NovoProds als eines großen Standardsoftwareherstellers geschuldet. 
Dieser Internationalisierungsweg und das damit verknüpfte Geschäftsmodell 
NovoProds implizieren klare Grenzen einer möglichen Standardisierung und 
Formalisierung der Arbeitsprozesse und bewahren damit die Abhängigkeit von 
den individuellen Selbstorganisations- und Problemlösungsfähigkeiten der Be- 
schäftigten als einer erfolgskritischen Ressource. Doch auch am Fall NovoProd 
lässt sich nachweisen, dass die entstehenden Formen der Reorganisation von 
Arbeit im Zuge der Internationalisierung der IT-Industrie nicht allein unter 
Rückgriff auf die verfolgten Internationalisierungswege der Unternehmen ver- 
standen werden können. So stellt der organisatorische Umgang mit den hohen 
Fluktuationsraten des indischen Arbeitsmarktes und den damit verknüpften 
Orientierungen der Beschäftigten hinsichtlich Gehalt und Karriere eine große 
Herausforderung für NovoProd dar und zwingt zu „indienspezifischen“ Anpas- 
sungen der Arbeitsorganisation und -kontrolle. 
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Auch in dieser Falldarstellung sollen zunächst einige Informationen zum Profil 
NovoProds gegeben werden (6.1), bevor ich mich dem von NovoProd verfolg- 
ten Modell der „verteilten Entwicklung“ zuwende und die daraus folgenden 
Implikationen für die Form der Arbeitsorganisation und -kontrolle im indischen 
Entwicklungszentrum von NovoProd diskutiere (6.2). In der Untersuchung der 
Kontrollstrategie steht dann die konkrete Umsetzung des Geschäftsmodells am 
indischen Standort im Zentrum des Interesses und ich möchte zeigen, wie sich 
auch bei NovoProd aus dem Wechselspiel zwischen den Anforderungen des 
Geschäftsmodells und den Bedingungen am indischen Arbeitsmarkt ein bestimm- 
ter Reorganisationsmodus der Arbeit entsteht, der im Gegensatz zu ServiceTec 
jedoch wesentlich permissivere Kontrollformen beinhaltet (6.3). 


6.1 Das Profil von NovoProd 


NovoProd ist ein deutsches IT-Unternehmen, das sich auf die Herstellung und 
Implementierung von betriebswirtschaftlicher Standardsoftware spezialisiert 
hat. Primäre Zielgruppe für die von NovoProd entwickelten Produkte sind 
traditionell vor allem Großunternehmen oder -organisationen. 

Im Jahr 2008 hatte NovoProd im Bereich der Softwareentwicklung über 15.000 
Beschäftigte, die an mehreren Entwicklungsstandorten weltweit arbeiteten. No- 
voProd ist damit in hohem Maße international aufgestellt - von den über 15.000 
Beschäftigten im Bereich der Softwareentwicklung arbeiteten 2008 nur ca. 40 % 
im Hauptquartier in Deutschland. 

Historisch war NovoProd zunächst neben Deutschland ausschließlich mit 
Entwicklungsstandorten in anderen Hochlohnregionen Europas und Nordame- 
rikas vertreten. Erst Ende der 90er Jahre änderte sich dieses Bild und NovoProd 
begann gezielt, Offshore-Kapazitäten in Niedriglohnregionen aufzubauen. Als 
erstes Offshore-Entwicklungszentrum wurde Ende der 90er das indische Ent- 
wicklungszentrum in Bangalore gegründet. 

Als Gründe für diese Neuausrichtung wurden von den befragten Vertretern 
des höheren Managements vor allem zwei Punkte genannt. 

Zum einen spielten - wenig überraschend - die Kostengesichtspunkte eine 
wichtige Rolle. Hatte NovoProd lange Zeit aufgrund der angebotenen Produkt- 
qualität eine dominierende Stellung auf dem von ihm bedienten Marktsegment, 
so sind NovoProd mit der Zeit zunehmend Wettbewerber erwachsen, die auch 
qualitativ mit ähnlichen Produkten aufwarten und in der Folge zunehmend 


! Alle Zahlen nach Geschäftsbericht von 2008. 
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Marktanteile erobern konnten. Aus diesem Grund befindet sich NovoProd un- 
ter stärker werdendem Konkurrenzdruck, der sich intern vor allem als stetiger 
Druck auf die Kosten der Produktentwicklung auswirkt. Demnach wurde die 
Verteilung der Arbeiten auf die verschiedenen Entwicklungszentren ab Ende 
der 90er Jahre auch zunehmend unter der Maßgabe verhandelt, einen möglichst 
großen Teil der Arbeit an Niedriglohnregionen ausführen zu lassen. 


„Und daran sehen Sie vielleicht auch eine Veränderung der Politik in dem 
Bereich: Früher konnten die Geschäftsbereiche den Standort völlig frei aus- 
suchen. Das heißt, wir [das indische Entwicklungszentrum - PF] mussten 
von Anfang an darauf achten, dass wir die gleiche Qualität liefern. Weil 
die Kollegen haben praktisch für ein Projekt 20 Head Counts zugebilligt 
bekommen, und die konnten sie jetzt in irgendeinem Standort aufbauen. 
Kosten spielten keine Rolle in dieser Firma, also zumindest nicht in diesem 
Bereich [lacht]. Das hat sich natürlich inzwischen verändert, ganz klar. 
Wir achten sehr, sehr genau auf die Kosten. Das heißt heute ist dann die 
Maßgabe erstmal: ‚Okay, low-cost Standort‘. Für bestimmte Sachen. Ist 
nicht immer so, aber für manche Sachen sagt man: ‚Okay, kann man das in 
einem low-cost Standort machen?“ (ND1)? 


Zum anderen war jedoch auch das verfügbare Arbeitskräfteangebot ein wichti- 
ger Grund für die Gründung der indischen Niederlassung. Nach Aussagen der 
befragten Manager sei es für NovoProd Ende der 90er schwierig geworden, in 
Deutschland neue Beschäftigte in ausreichender Zahl und mit adäquater Qualifi- 
kation zu rekrutieren. Daher wurde entschieden, den Großteil des Wachstums in 
den Offshore-Entwicklungszentren, wie z.B. Indien voranzutreiben, in denen es 
leichter gewesen sei, schnell eine größere Zahl von Entwicklern einzustellen. 


„Gut, wir hatten da letztlich das beste Gefühl vom Job-Markt her. Die 
Motivation war ja ohnehin im Jahr ’99, dass wir hier nicht mehr genug 
Leute kriegen. Da lief ja gerade die erste Internet-Welle heiß, und die 
Startups haben natürlich einen unheimlich Zulauf gehabt von intelligenten 
jungen Menschen. Für ein etabliertes Unternehmen, was so ein bisschen 
als altmodisch galt, war es auch ein bisschen schwierig, gute Leute hier 
zu kriegen. Wir haben auf manche Stellenanzeigen hier überhaupt keine 
Response mehr bekommen. [...] In Indien war das eben anders. Da konnten 
wir halt in bestimmten Bereichen in Indien sehr zügig wachsen.“ (ND1) 


Dementsprechend rasant verlief auch das Wachstum des indischen Standortes 
innerhalb NovoProds. Ende der 90er Jahre gegründet, arbeiteten 2008 bereits 


? Nähere Informationen zu den zitierten Gesprächspartnern bei NovoProd finden sich in Tabelle 
8.2 (S. 292) im Anhang. 
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mehr als 3000 Personen dort. Das indische Entwicklungszentrum ist damit in 
kurzer Zeit zum zweitgrößten Standort NovoProds aufgestiegen. 

Die im Rahmen dieser Studie untersuchte Abteilung ist Teil des Forschungs- 
und Entwicklungsbereiches von NovoProd, in ihr wird ein neues Software- 
Produkt entwickelt. 


6.2 Global verteilte Entwicklung bei NovoProd 


In seinem globalen Geschäftsmodell versucht NovoProd, sich von einem durch 
einen Vertreter des höheren Managements wie folgt definierten „Standardansatz“ 
des Offshoring abzugrenzen: 


„Aber jetzt, um ganz konkret zu werden: im Prinzip der klassische Ansatz 
dieses Offshorings, den jetzt die typischen indischen IT-Firmen auch fahren, 
[...] ist halt: Man hat hier einen Projektmanager onsite beim Kunden - also, 
das kann ja irgendjemand sein, und das kann auch ein interner Kunde sein 
- und einen offshore Projektmanager und dann eine große Box darunter 
mit Leuten. Eigentlich kommunizieren nur 2 Leute miteinander und die 
anderen nicht. Und dann gibt es da vielleicht noch so ’nen Delivery-Arm, 
der das dann wieder zurückliefert, was da gemacht wurde. Das ist, sagen 
wir mal, so ein Standard-Ansatz.“ (ND1) 


Dieser „Standardansatz“, der stark an das im vorigen Kapitel dargestellte „Global 
Delivery Model“ des indischen Serviceproviders erinnert, beinhaltet nach Ansicht 
des zitierten Gesprächspartners demnach verteilte Projektteams, deren Mitglieder 
jedoch kaum direkt miteinander in Kontakt stehen, sondern primär über die 
jeweiligen Projektmanager an den Standorten kommunizieren. 

Gegenüber diesem „Standardansatz“ setze NovoProd nach Aussagen desselben 
Managers strategisch eher auf „verteilte Entwicklung“. Grundlage der „verteil- 
ten Entwicklung“ ist eine modulare Produktarchitektur, die sich in einzelne 
Komponenten zerlegen lässt. Diese Komponenten werden anschließend an unter- 
schiedlichen Standorten parallel entwickelt. Dabei werde bei NovoProd darauf 
geachtet, dass auch die Standorte in Niedriglohnregionen jeweils umfassende 
Funktionen wahrnehmen und nicht nur kleine Zuarbeiten zu anderen Modulen 
leisten, wie ein Manager anhand seines vorherigen Projektes erläutert: 


? Diese Zahl bezieht sich auf den Zeitpunkt der Untersuchung. Bei Erscheinen dieser Studie wird 
die Zahl noch einmal wesentlich höher sein, da der Standort in der Zeit nach der Befragung 
personell verstärkt wurde. 
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„Das Zielmodell, das ich auch in der anderen Abteilung hatte, [...] war ganz 
klar: Gebt bitte ein Arbeitsthema als Ganzes nach unten. Ja? [...]. Produk- 
tion, Vor-Produktionsplanung und Detailed Scheduling habe ich damals 
als Ganzes nach Indien gegeben. Das war eines der richtig komplizierten 
Themen, auch so technisch höchst kompliziert. Es geht um finite Planung - 
ich weiß nicht, inwieweit Ihnen das was sagt. [...] Und das ist ein wirklich 
schwieriges Thema gewesen. Das haben wir komplett nach Indien gegeben. 
Und es hat sehr gut funktioniert. Das war - ich hatte 20 Leute, die gesagt 
haben, es funktioniert nicht. Nie, so ein kompliziertes Thema, das würden 
die nie begreifen, was wir da in den letzten zehn Jahren programmiert ha- 
ben und in eins runter gegeben. [...] Wir haben nur einmal am Anfang eine 
Situation gehabt, wo wir lösen mussten, aber sonst hat es funktioniert.“ 


(ND6) 


Modulare Strukturen bedeuten dabei keinesfalls, dass die einzelnen Komponenten 
gänzlich unabhängig voneinander wären. Vielmehr bestehen starke Interdepen- 
denzen, weil die einzelnen Komponenten zeitlich parallel entwickelt werden. 
So gibt es stets Situationen, in denen Änderungen an einem Modul auch Aus- 
wirkungen auf andere Module haben, was bei „verteilter Entwicklung“ stets 
hohe Kommunikations- und Kooperationsanforderungen zwischen den Modulen 
begründet. 

Angestrebt wird bei NovoProd in Abgrenzung zum beschriebenen „Stan- 
dardansatz“ eine Struktur, in der nicht nur die Projektleiter an den unterschied- 
lichen Standorten, sondern vielmehr die Entwickler direkt miteinander kom- 
munizieren und kooperieren, der Kontakt also auch auf der untersten Ebene 
stattfindet: 


„Wir machen’s eigentlich eher tief integriert. Das heißt, wo der Projekt- 
Lead sitzt, ist völlig - der kann überall sitzen, und wir fahren eigentlich 
eine Integration auf Entwickler-Level, also die Entwickler kennen sich 
untereinander. Und dann haben wir eben oft in einem Projekt - von mir 
aus - 5 in Deutschland, 5 in Indien. Im anderen ist einer in Deutschland, 
10 in Indien. Dann haben wir auch Projekte, da sind vielleicht 10 Leute 
hier und 2 in Indien oder so. Und der Projekt-Lead ist mal in Indien und 
mal hier. Also das ist eine ganz andere Art und Weise der Zusammenarbeit. 
Ich würde mal sagen, dass ein großer Teil unserer Projekte so gemanaged 
wird, und nur ein sehr geringer Anteil eigentlich so ist, dass da nur 2 Leute 
miteinander kommunizieren.“ (ND1) 


Zudem solle vermieden werden, dass eine klare Asymmetrie zwischen den Stand- 
orten in Bezug auf die Zuteilung planender und ausführender Tätigkeiten entsteht, 
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indem die Entwicklungszentren in Niedriglohnregionen die bei NovoProd so 
genannte „Ownership“ für die von ihnen bearbeiteten Komponenten erhalten. 
Gemeint ist damit, dass die an den verschiedenen Standorten lokalisierten Module 
auch von diesen Standorten verantwortet werden. 

Die Zielstruktur, die NovoProd in Bezug auf ihr globales Geschäftsmodell 
anstrebt, ist also ein Netzwerk aus unterschiedlichen Standorten auf Basis modu- 
larer Produkt- und Organisationsstrukturen. Dabei sollen auch Standorten in 
Niedriglohnregionen - wie Indien - weitreichende Befugnisse und Verantwort- 
lichkeiten für die von ihnen bearbeiteten Komponenten übertragen werden. 


Wenden wir uns im Folgenden der bei NovoProd vorfindbaren Realstruktur zu, 
so finden sich auf den ersten Blick viele Merkmale der Zielstruktur verwirklicht. 
Die im Rahmen dieser Studie untersuchte Abteilung ist Teil der Forschungs- 
und Entwicklungsabteilung NovoProds. Ihr obliegt die Entwicklung eines neuen 
Software-Produkts, das in verteilter Entwicklung hergestellt werden soll. Das 
zu entwickelnde Produkt ist eine webbasierte Applikation, die auf einer bereits 
existierenden Plattform aufbaut, die der Applikation die nötigen Funktionen zur 
Verfügung stellt, deren Funktionsumfang jedoch von der Applikation in einer 
neuartigen Art und Weise aufbereitet und zur Verfügung gestellt wird. 

In das Entwicklungsnetzwerk sind im wesentlichen drei grosse Einheiten 
involviert, die sich auf den deutschen und den indischen Standort verteilen*. Ein 
Projektmanager beschreibt deren Aufgabenprofile in der globalen Arbeitsteilung 
folgendermaßen: 


„Yeah, usually Vision? tries to give what the customers want. So they give 
the requirements, so to say. And then Plattform tries to see, whether they 
can do it or not do it or whatever. And we, in Application, we build ... the 
entire application on top of this platform. So the platform is more generic. 
We do some of the basics and we build the actual application, and the user 
interface and everything. So, it’s a combination of all the three.“ (NI11) 


Die erste Einheit ist Vision. Vision ist fiir die Anforderungsanalyse fiir das neue 
Produkt zustandig, erarbeitet somit in enger Kooperation mit zentralen Kun- 
denunternehmen die notwendigen Merkmale und Funktionen des Programms 


* Es werden einige kleinere Zuarbeiten auch von anderen Standorten, sowohl aus Hoch- als auch 
Niedriglohnregionen, bezogen, diese stellen jedoch eher periphere Kooperationspartner dar, so 
dass sich im Folgenden auf die Zusammenarbeit zwischen dem indischen und dem deutschen 
Standort konzentriert wird. 

> Die Namen der an der Entwicklung beteiligten Organisationseinheiten wurden aus Anonymi- 
sierungsgründen geändert - auch in den Zitaten. 
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und erstellt in Usability-Studien auch Richtlinien für das grafische Design der 
Applikation. Dieser Teil ist in der Firmenzentrale NovoProds in Deutschland 
situiert. 

Die zweite Einheit - Plattform - entwickelt die dem neuen Produkt zugrun- 
deliegende Plattform. Diese Einheit befindet sich ebenfalls im Hauptquartier in 
Deutschland°. 

Die dritte Einheit schließlich - Application - die in dieser Studie auch im 
Fokus steht - entwickelt die Applikation gemäß der von Vision erarbeiteten 
Anforderungen und auf Grundlage der vom Plattformteil bereitgestellten Funk- 
tionalitäten. Dieser Teil des Entwicklungsnetzwerkes ist schwerpunktmäßig im 
indischen Entwicklungszentrum situiert. Eine derart umfassende Übergabe von 
Entwicklungsaufgaben an einen Niedriglohnstandort habe es nach Aussagen von 
Vertretern des höheren Managements in der Geschichte NovoProds bisher noch 
nicht gegeben. Zwar hätten andere Entwicklungszentren in Niedriglohnstand- 
orten bereits einzelne Module von Applikationen entwickelt, ein derart zentraler 
Teil einer neuen Applikation sei allerdings noch nie an einen Niedriglohnstandort 
übertragen worden. 

Nach dem bisher Gesagten finden sich bei NovoProd also - zumindest for- 
mal - jene Strukturen, die als Zielstruktur der globalen Arbeitsteilung skizziert 
wurden: modulare Produkt- und Organisationsstrukturen mit weitreichenden 
Kompetenzen auch der in das Entwicklungsnetzwerk eingebundenen Niedrig- 
lohnstandorte. 


Doch gerade der letzte Punkt - der Umfang des Verantwortungsbereiches des 
indischen Standortes - stellt einen sensiblen Punkt im globalen Entwicklungs- 
modell NovoProds dar. Um die Probleme, die um dieses Thema kreisen, zu 
verstehen, muss man zunächst etwas tiefer in die Geschichte des untersuchten 
Entwicklungsprojektes einsteigen. 

Der Entwicklung des Produkts und damit auch dem Start des untersuch- 
ten Projektzusammenhanges ging eine Phase der Forschung voraus, in der u.a. 
notwendige Spezifikationen für das neue Produkt gesammelt und die techni- 
sche Realisierbarkeit desselben getestet wurden. Diese Forschungsphase wurde 
von sehr erfahrenen Entwicklern NovoProds in Deutschland durchgeführt. Als 
schließlich der Entschluss feststand, das Produkt tatsächlich zu entwickeln, und 
als zusätzlich beschlossen wurde, das Produkt im Entwicklungszentrum in Indien 


é Auch diese Abteilung hat mittlerweile einen kleinen Ableger in Bangalore, jedoch spielt dieser 
Teil bei der Entwicklung des hier betrachteten Produkts keine Rolle, so dass er im Folgenden 
auch unberücksichtigt bleibt. 
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entwickeln zu lassen, wurde dem Team, das die Vorarbeiten in der Forschungs- 
phase durchgeführt hatte, auch die Aufgabe übertragen, das Entwicklungsteam 
in Bangalore aufzubauen und anzuleiten. Ein Mitglied des damaligen Forschungs- 
teams beschreibt die Situation folgendermaßen: 


„Ich habe im April 2004 gewechselt, zu einem damaligen Forschungsprojekt. 
Da war ich dann eben für den neuen Bereich zuständig, den ich dann mit 
einer Gruppe hier anfangen musste, zu entwickeln. [...] Es ging darum, das 
eben in einem neuen Setup, mit neuen Zielen für einen neuen Zielmarkt 
auch aufzuarbeiten. Und man mal technologisch untersucht, wie man es 
eben realisieren kann. Das haben wir dann gemacht. Ende 2004, Anfang 
2005 ist dieses damalige Forschungsprojekt dann aus der reinen Forschung 
in eine etwas angewandtere Forschung übergangen, in dem Sinne, dass man 
wirklich in eine neue Produktentwicklung gegangen ist, das Ganze dann 
auch geteilt hat in einen Plattformteil, der das Backend ausmacht und einen 
Frontendteil, der eben eher das UI und die Benutzeroberfläche ausmacht. 
[...] Und wie gesagt, das war dann Anfang 2005, dass ich dann bei diesem 
Split praktisch gefragt worden bin und mich dann auch entschieden habe, 
in diesen Lösungsteil, in diesen UI-Ieil, Benutzeroberflachen-Teil zu gehen, 
der dann sehr starken Kontakt mit Indien gehabt hat.“ (ND7) 


Als erfahrene Beschäftigte mit der Aufgabe betraut, den indischen Projektzu- 
sammenhang auf- und auszubauen, nahmen die Mitglieder des ehemaligen For- 
schungsprojektes eine Position als sogen. „Brückenköpfe“ innerhalb des Entwick- 
lungsnetzwerkes ein. Als „Brückenköpfe“ waren sie zwar organisatorisch der in 
Indien verorteten Abteilung zur Entwicklung des neuen Produktes (Application) 
zugeteilt, allerdings räumlich im deutschen Hauptquartier NovoProds situiert. In 
der Position der „Brückenköpfe“ bündelten sich zunächst die schwerpunktmäßig 
kommunikativen und planenden Tätigkeiten für Application. 

So kümmerten sich die Brückenköpfe zum einen um die Kommunikation 
und die Kooperation mit den beiden anderen an der Entwicklung beteiligten 
Abteilungen Vision und Plattorm. Koordiniert und geplant wird die Gesamtent- 
wicklung des Produkts über ein spezielles Steuerungsgremium, in dem Vertreter 
aller drei an der Entwicklung beteiligten Bereiche repräsentiert sind. Die Tref- 
fen dieses Steuerungsgremiums sind für die weitere Entwicklung von zentraler 
Bedeutung: zu implementierende Funktionen werden hier genauso diskutiert 
und beschlossen, wie zentrale Design- und Konzeptionsfragen. Beschlüsse, die 
hier getroffen werden, sind anschließend für die Umsetzung in den Einheiten des 
Entwicklungsnetzwerkes bindend. Den Treffen dieses Steuerungsgremiums, die 
vorwiegend in Deutschland stattfinden, weil die Mehrheit der Projektteile dort 
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ansässig ist, wohnten die Brückenköpfe für ihre indischen Counterparts bei, da 
für sie im Gegensatz zu ihren indischen KollegInnen keine Zeitverschiebung zu 
Deutschland existiert und sie damit ein größeres Zeitfenster für Meetings und 
Absprachen haben. Zum anderen fielen am Anfang der Projektlaufzeit auch die 
Projektmanagementfunktionen für Application den deutschen Brückenköpfen 
zu. 

Damit war die Arbeitsteilung zwischen den in Deutschland befindlichen 
„Brückenköpfen“ und dem in Indien situierten Teil von Application zunächst dem 
beschriebenen „Standardansatz“ recht ähnlich: Design- und Architekturentschei- 
dungen im Steuerungsgremium und Projektmanagementaufgaben wurden von 
den Brückenköpfen in Deutschland erledigt, den indischen Entwicklern wurde 
mehr oder weniger ausschließlich die Umsetzung der in Deutschland getroffenen 
Entscheidungen überlassen, wie ein damaliger Briickenkopf klarstellt: 


„Wir sind nach Indien gefahren und haben das Projekt detailliert durch- 
geplant. Wir haben work packages definiert, haben die terminiert, dann 
einen Kapazitätsabgleich gemacht.“ (ND4) 


Der Hauptgrund dafür lag nach Ansicht der beteiligten Brückenköpfe vor allem 
in dem starken Erfahrungsgefälle zwischen den deutschen, schon lange bei No- 
voProd arbeitenden, und den in Bangalore für dieses Projekt weitgehend neu 
eingestellten Entwicklern: 


„Okay, also die Situation war wie folgt: Das Team in Indien war jung, und 
war partiell noch gar nicht eingestellt. Wir hatten alle relativ viel Erfahrung 
hier in Deutschland, im deutschen Teil des Teams. Wir haben natürlich 
gleich die Projektleitung übernommen.“ (ND4) 


Allerdings entsprach dieses Vorgehen - wie weiter oben bereits erwähnt - nicht 
dem Ziel von NovoProd in Bezug auf die Einbindung des indischen Standortes. 
Dementsprechend sollte diese klare Arbeitsteilung zwischen planenden und aus- 
führenden Tätigkeiten auch lediglich am Anfang des Projektes bestehen. Mit 
der Zeit sollte das indische Entwicklungszentrum selber die Entwicklung ver- 
antworten oder - wie es bei NovoProd heißt - die „Ownership“ für die neue 
Applikation übernehmen. Daher war die Position der Brückenköpfe ursprüng- 
lich auch als eine temporäre angelegt: die Brückenköpfe sollten das neue Team in 
Indien anlernen und dann möglichst schnell abgezogen werden: 


„Ursprünglich war es unser Ziel eigentlich, sich nach einem Jahr oder 
anderthalb Jahren praktisch überflüssig gemacht zu haben, und dass das 
Ganze alleine läuft.“ (ND7) 
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Ein anderer Brückenkopf macht es ganz deutlich: 


„Also mein Ziel wäre, dass wir den deutschen Teil unseres Teams komplett 
wegkriegen würden.“ (ND4) 


Im Zuge dieses Abbauversuches wurde in den letzten Jahren versucht, vermehrt 
Verantwortung an das indische Entwicklungszentrum abzugeben: 


„Also ich habe ja dann mehrere ganz junge indische Kollegen am Anfang 
betreut. Und da habe ich dann sozusagen die Aufgaben, vor allem am An- 
fang, auch direkt zugeteilt. Und zwar auch einzeln. Und dann habe ich 
später meistens, da hat sich dann einer bei rauskristallisiert, der sehr gut 
mit Organisieren und Verteilen war. Der hatte einen ganz guten Überblick 
und dem habe ich dann auch diese Aufteilung ein bisschen in die Hand 
gegeben und gesagt: ‚Hier, die folgenden Dinge sind zu machen‘. Habe 
dann ein bisschen mit ihm gesprochen: ‚Wie könnte man es machen? Was 
ist das Wichtigste;Und dann hat er sozusagen auch intern das ein bisschen 
geregelt. Er war sozusagen zwar hierarchisch nicht über den anderen, aber 
er hat ein bisschen mehr vom Entscheidungskuchen abbekommen. Und ich 
habe dann aber schon an einigen Stellen, wo ich gezielt Leute in bestimmte 
Richtung entwickeln wollte - oder sie hindrängen wollte, gesagt: ‚Das kann 
der sein, der vielleicht später in dem Bereich der ganzen Konfigurationsta- 
bellen, die wir haben, mehr machen sollte‘- da habe ich dann jemanden 
bestimmt und gesagt: ‚Das machst Du jetzt.‘“ (ND2) 


So sei in der Folge das Verhältnis zwischen den deutschen Brückenköpfen und 
den indischen Beschäftigten auch weniger hierarchisch geworden, da viele Pro- 
jektmanagementaufgaben nun von der indischen Seite wahrgenommen würden, 
wie folgender Brückenkopf bestätigt: 


„Doch, es [das Projektmanagement von Deutschland aus - PF] ist natürlich 
weniger geworden. Aber das war auch unser Ziel, dass es weniger wird, dass 
die Leute selbstständiger arbeiten.“ (ND4) 


Doch obwohl sich somit bei NovoProd ganz deutlich die Versuche abzeichnen, 
dem indischen Team zunehmend weitreichendere Steuerungsfunktionen über 
die Entwicklung zu übertragen, war zum Zeitpunkt der vorliegenden Untersu- 
chung eine vollständige „Ownership“ des indischen Teils von Application für die 
Entwicklung der Kernapplikation nicht gegeben, wie sich aus der Schilderung 
des Aufgabenprofils eines Brückenkopfes ersehen lässt: 


„Ich bin ein sogenannter Brückenkopf. Das heißt, ich bin einem indischen 
Projektteam mit diesem indischen Projektleiter zugeordnet. Ich soll das 
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Projekt gemeinsam mit ihm leiten. Und die Aufgabenverteilung ist in etwa 
so: Ich bin für Software-Architektur, Verhandlungen mit deutschen anderen 
Entwicklungsgruppen zuständig. Wir haben unser Vision-Team, die also 
das Produkt spezifizieren, die sitzen hier in Deutschland. Und auch die 
Basis, auf der wir aufbauen, sitzt größtenteils in Deutschland. Und diese 
technischen Verhandlungen soll alle ich führen, auch dort weitreichend 
Entscheidungen treffen. Und sein [des indischen Projektleiters - PF] Fokus 
ist eher darauf, die Exekution in Bangalore zu treiben. Das heißt, wir 
besprechen gemeinsam: Was ist zu tun? Wie wollen wir die Architektur- 
Aufgaben letztendlich lösen, oder die Fragestellung, wo Konflikte sind mit 
anderen Gruppen? Da entscheiden wir dann gemeinsam. Und dann ist er 
der, der sozusagen täglich den Fortschritt nachvollzieht in Indien mit den 
jüngeren Projektteilnehmern.“ (ND2) 


Zum einen sind es also immer noch primär die Brückenköpfe, die an den Treffen 
des Steuerungsgremiums in Deutschland für den Application-Bereich teilnehmen’, 
zumal ihre vermittelnde Funktion zwischen den deutschen und den indischen 
Teams (nach Ansicht des folgenden Brückenkopfes) als erfolgskritisch für eine 
gelingende Kooperation innerhalb des Entwicklungsnetzwerkes angesehen wird: 


„Und, also, ich denke, man braucht schlicht und einfach ein paar Leute, 
die mehr oder minder so halbwegs verstehen, wie beide Seiten ticken. Ich 
meine, klar, man versteht immer besser, wie die deutsche Seite tickt, weil 
man es ja nun mal ist, als wenn man jetzt einfach nur sagt: Okay, da ist 
Vision, die schicken ihre Specs rüber und Plattform schickt auch irgend- 
welche Specs rüber. Und das indische Team macht dann irgendwas daraus. 
Das würde nicht funktionieren. [...] Also wenn man verteilt entwickelt, 
dann muss man halt viel miteinander reden und man muss auch Austausch 
zwischen den Lokationen haben, so dass man wirklich Leute hat, die sich 
auskennen.“ (ND5) 


Zum anderen stellt sich auch die Ubergabe von Projektmanagementfunktio- 
nen an den indischen Teil von Application schwieriger dar, als es zunächst vom 
Management erwartet wurde. So unterscheidet sich das Ausmaß, in dem Projekt- 
managementfunktionen mittlerweile nach Indien vergeben wurden, innerhalb 
der Einheit z.T. stark. Application ist intern in verschiedene Teams unterteilt. 
Jedes dieser Teams bearbeitet einen Ausschnitt der Gesamtapplikation, zumeist 
einen bestimmten Funktionsbereich und hat einen separaten Brückenkopf auf 
der deutschen Seite, der speziell für dieses Team zuständig ist. Vergleicht man nun 


7 Manchmal werden auch indische Manager oder Beschäftigte per Videotelefonat in diese Treffen 
eingebunden, aber meist nehmen nur die Brückenköpfe an diesen Treffen teil. 
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diese Teams untereinander im Hinblick auf die Übergabe von Steuerungsfunk- 
tionen an den indischen Standort, so fallen z. T. große Unterschiede auf. Einige 
indische Teams, wie das des folgenden Brückenkopfes, erledigen die Aufgabe der 
Definition und Zuteilung von Arbeitsaufgaben mittlerweile gänzlich selbständig 
und in Eigenverantwortung: 


„Das wird komplett in Indien gemacht. Ich mache das gar nicht mehr. 
Früher habe ich das sehr genau gemacht. Zwischenzeitlich überhaupt nicht 
mehr.“ (ND4) 


Andere Teams stehen jedoch noch immer unter intensiver Beobachtung und 
Steuerung von Deutschland aus. Der Brückenkopf eines solchen Teams antwortet 
auf die Frage, ob er eine Möglichkeit sehe, verstärkt Projektverantwortlichkeiten 
nach Indien zu übergeben: 


„Nicht in dieser Phase. Wir werden, und das ist mein Ziel, zweite Hälfte 
nächsten Jahres ist mein Ziel, das ganze Projekt nach Indien zu vergeben. 
Wo ich sage, das ist ein Auftrag, das ist das Problem, make it, kein Thema.“ 


(ND6) 


Grundsätzlich kann daher festgestellt werden, dass das ehrgeizige Ziel, den deut- 
schen Teil der Einheit möglichst schnell überflüssig zu machen und abzubauen, 
zum Zeitpunkt der Untersuchung beim Großteil der interviewten Brückenköpfe 
der recht ernüchternden Einsicht Platz gemacht hat, dass es dieser deutschen 
Brückenköpfe zumindest gegenwärtig weiter bedarf und eher mittelfristig an eine 
weitreichende Übergabe der Projektverantwortung an den indischen Standort 
gedacht werden kann: 


„Mittlerweile ist es klar, dass es kurzfristig nicht möglich sein wird, sich 
überflüssig zu machen, sondern, dass es eher mittelfristig noch gehen wird. 
[...] War, wie gesagt, insgesamt auch von der Organisation her ein bisschen 
anders geplant, wenn ich das richtig verstehe.“ (ND7) 


Dementsprechend ist die dem indischen Team nur teilweise zugestandene Verant- 
wortung für die Entwicklung der Applikation innerhalb von Application auch 
ein sehr umstrittenes und konfliktgeladenes Thema und führt auf der Seite der 
indischen Beschäftigten zu Beschwerden und Unmut. 


„I mean, still the work is predominantly Germany-centric. [...] Slowly it’s 
being decentralized, but as I said, it’s not really fast enough. But it’s getting 
decentralized, that something is moving out of Germany. But people still 
have a perception that it’s more Germany-centric.“ (NI7) 
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So fühlen sich viele Entwickler - wie auch der im Folgenden zitierte - von 
zentralen Entscheidungen über das Produkt ausgeschlossen, da diese innerhalb 
des Steuerungsgremiums unter den deutschen Beschäftigten der anderen an der 
Entwicklung beteiligten Einheiten und den ebenfalls deutschen Brückenköpfen 
getroffen würden: 


„Code is owned by us, you know, because we are developing it. But the 
whole design and other processes actually - we don’t have much say in that. 
Nobody listens to us. We have to shout. Seeing that, if we are at Germany, 
we can participate in more and more meetings and more and more decision 
meetings. We can influence - and we can change the product as well. Make 
other changes. But here, there are not many people listening to us. [...] 


Nobody asks!“ (NI9) 


Das bedeutet jedoch nicht, dass das indische Entwicklungszentrum gar nicht in 
diese Entscheidungsprozesse involviert ist. Die Verantwortung fiir die Organi- 
sation der Entwicklung - also die praktische Umsetzung - liegt in der Hand 
des in Indien situierten Teams von Application, und entsprechend wird dieses 
von den Brückenköpfen auch in die Diskussion über die weitere Entwicklung 
des Produktes einbezogen. Allerdings werden die Beschäftigten im indischen 
Entwicklungszentrum primär in Bezug auf die Realisierbarkeit der im Steue- 
rungsgremium entwickelten Pläne befragt, wie folgender Projektleiter ausführt: 


„Managers from Germany, they participate in a meeting. And then they 
decide about something: That this should be there, some high level scoping 
and all. They will do some high level scoping for the work. [...] During high 
level scoping - they do not finalize in one meeting the high level scoping, 
but they would - managers would actually directly talk to developer and 
they would ask for some effort estimation of the developer. So as to better 
match up the scoping. So that it looks realistic.“ (NI22) 


Vorschlage von indischer Seite hinsichtlich der Konzeption und Planung werden 
jedoch in diesen Treffen kaum gehört bzw. angenommen. 


„Yeah. We have to stick to the decision taken by the steering committee 
generally. But if you get a better solution - then you obviously can propose 
it. But it is generally one of the things, that are not easy - you are not able 
to get through.“ (NI23) 


Als Hauptgrund dafür, dass dieser Widerspruch zwischen der strategischen Ziel- 
und der bei Application gelebten Realstruktur fortbesteht, wird von den deut- 
schen Brückenköpfen weiterhin vor allem fehlende Erfahrung und fehlendes 
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Wissen der indischen Kollegen in Bezug auf die bei NovoProd hergestellten 
Produkte und die Arbeitsabläufe genannt: 


„Das ist der Punkt, ich habe einen einzigen, also ich habe zwei Senior Leute 
in Indien. Davon ist der Personalmanager, der logischerweise schon länger 
dabei ist, der eine, und dann den zweiten, einen Projektleiter. [...] Aber 
die Situation ist die, dass ich zurzeit sonst niemanden da habe, der drüben 
Senior ist. [...] Das ist ein einfacher Entwicklungsschritt. Sie müssen die 
Evolution, die Lernkurve der Leute pushen, pushen, pushen, dass sie hoch- 
kommen, und dann können Sie einzelne Tasks wirklich sauber nach unten 
geben, würde ich sagen. Das hast du begriffen, das sind Sachen, die brau- 
chen wir jetzt nicht hier zu machen, auch wenn es technisch kompliziert 
ist. Es hängt nicht am Technischen, oder ob es kompliziert ist oder nicht. 
Das hängt einfach davon ab - da nehme ich dieselben Maßkriterien wie hier 
an - wenn derjenige es leisten kann, dann challenge ich ihn damit und dann 
gebe ich es ihm.“ (ND6) 


Auch ein weiterer Brückenkopf führt auf die Frage, ob er es für möglich halte, 
auch kurzfristig mehr Verantwortung an das indische Team zu übergeben, aus: 


„Glaube ich nicht. Also ich habe das Gefühl, dass, zumindest Stand heute, 
viel zu wenig Wissen und Erfahrung in Indien ist, viel zu wenig langfristiges 
Denken auch. Das heißt, es ist so, dass ich bei den indischen Kollegen den 
einen oder anderen sehr, sehr langfristig denkenden Kollegen sehe. Aber das 
sind zu wenige, Stand heute. Und die Frage ist halt: Was ist in fünf Jahren, 
wenn jetzt von den Leuten, die jetzt in massıven Zahlen eingestellt worden 
sind, wenn da jetzt mehrere davon übrig bleiben und nicht die Firma 
verlassen haben: wird dann ein starkes Architektur-Gründlichkeitsdenken 
dort wirklich Einzug erhalten?“ (ND2) 


Der von beiden Interviewpartnern konstatierte Mangel an Wissen und Erfahrung 
bezieht sich dabei nicht nur auf die Tatsache, dass das indische Team am Anfang 
der Entwicklung noch neu war und sich erst einarbeiten musste. Der zuletzt 
zitierte Brückenkopf erwähnt vielmehr bereits das langfristige Denken, das 
seiner Meinung nach im indischen Teil des Teams fehle. Angesprochen sind 
von ihm damit die hohen Fluktuationsraten des indischen Standortes. So war 
es für NovoProd nicht nur ein Problem, am indischen Standort zu Beginn des 
Projektes neueingestellte Beschäftigte anlernen zu müssen, sondern der stetige 
Abgang von Beschäftigten macht das Anlernen neuer Beschäftigter zu einer 
permanenten Aufgabe und unterminiert damit auch kontinuierlich den Aufbau 
von Wissen und Erfahrung. So sind es auch die Teams, die in den letzten Jahren 
mit erhöhter Personalfluktuation konfrontiert waren, die nach wie vor unter 
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direkter Kontrolle durch die deutschen Brückenköpfe stehen, wohingegen jene, 
deren Besetzung stabiler war, erweiterte Selbststeuerungsfunktionen aufweisen 
können®. Zwar hat NovoProd grundsätzlich mit geringeren Fluktuationsraten 
zu kämpfen als z.B. ServiceTec, doch ihre Reduzierung hat auch bei NovoProd 
hohes Gewicht. Schließlich hängt die Realisierung der strategischen Zielstruktur 
ganz wesentlich vom Aufbau ausreichender Wissens- und Erfahrungsbestände im 
indischen Entwicklungszentrum ab: 


„So, they [die deutschen Beschäftigten im Hauptquartier NovoProds - PF] 
become an expert over a period of time and they become masters in that. 
And same thing doesn’t happen in India, because people come, leave, like ... 
they’ll again come and again leave. [...] Those guys, Germans, they cannot 
give very critical work, because they know, that: ‘ok, you don’t have the 
expertise’. And by the time somebody has this expertise, he will move out. 
[...] So that’s why we try to emphasize that: ‘ok, you need to spend some 
time in NovoProd - three years, four years. And then only you start getting 
more important, critical...’ Thats why we try to retain people, and put a 
lot of stress on that.“ (NI4) 


Mit den hohen Fluktuationsraten ist - wie auch bei ServiceTec - eine wich- 
tige Rahmenbedingung der Gestaltung von Arbeitsorganisation im indischen 
Entwicklungszentrum benannt, und wir werden später in der Analyse der be- 
trieblichen Kontrollformen noch ausführlich darauf zurückkommen. 


Zunächst kann aber in Bezug auf das von NovoProd verfolgte globale Geschäfts- 
modell festgehalten werden, dass auch gegenwärtig zwischen der intendierten 
Zielstruktur und der Realstruktur ein Widerspruch fortbesteht. Doch obgleich 
die an den indischen Standort übergebenen Projektmanagementfunktionen ge- 
genwärtig nicht so weitreichend sind, wie von NovoProd intendiert, stellt die 
strategische Zielsetzung, dem indischen Entwicklungszentrum diese langfristig 
zukommen zu lassen, doch ein entscheidendes Merkmal des von NovoProd 
verfolgten Geschäftssmodells dar. Es wird sich bei der folgenden Analyse der 
im indischen Entwicklungszentrum verfolgten Kontrollstrategie zeigen, dass 
dieses Geschäftsmodell auch beinhaltet, dass NovoProd wesentlich stärker auf 
die Selbststeuerungsfähigkeiten der Beschäftigten setzt und sich dort somit eine 
deutlich permissivere Kontrollstrategie identifizieren lässt, als es im Falle von 
ServiceTec der Fall ist. 


8 Die Gründe dafür, warum bestimmte Teams seit Beginn des Projektes stabiler waren als andere, 
konnten leider im Rahmen dieser Studie nicht in Erfahrung gebracht werden. 
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Diese strategische Orientierung ist am indischen Standort nicht unproblema- 
tisch. Die Situation auf dem indischen Arbeitsmarkt wurde bereits als maßgebli- 
cher Grund identifiziert, warum NovoProd gegenwärtig seiner Zielstruktur in 
Bezug auf die Einbindung des indischen Entwicklungszentrums hinterherhinkt, 
da die hohen Fluktuationsraten den Aufbau von Wissens- und Erfahrungsbestän- 
den der indischen Beschäftigten untergraben. Scheint das Geschäftsmodell daher 
also durch die hohen indischen Personalfluktuationsraten besonders gefährdet 
zu sein, so wird sich zeigen lassen, dass es auf der anderen Seite auch Möglich- 
keiten bietet, diesen in einer ganz spezifischen Weise gegenüberzutreten und sie 
organisatorisch zu bearbeiten. 
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6.3 Betriebliche Kontrollstrategien bei NovoProd im 
Entwicklungszentrum in Bangalore 


Im Folgenden soll die im indischen Entwicklungszentrum von NovoProd verfolg- 
te Kontrollstrategie anhand der in Kapitel 4.3 genannten Aktivitätsfelder genauer 
analysiert werden. Dabei bezieht sich die Untersuchung primär auf die am indi- 
schen Standort lokalisierte Einheit Application und ihre deutschen Brückenköpfe. 
Die beiden anderen an der Entwicklung beteiligten Einheiten Vision und Platt- 
form weisen keine Offshore-Komponenten auf und werden daher im Folgenden 
ausschließlich in ihrer Rolle als Kooperationspartner von Application behandelt. 

Wie bei der ersten Fallstudie gliedert sich das Kapitel in die Beschreibung der 
Aktivitäten des Managements in den vier Aktivitätsfeldern und eine abschlie- 
ßende, zusammenfassende Darstellung und Bewertung der Kontrollstrategie 
NovoProds. 


6.3.1 Aufgabenorganisation 


Aufgabenschwerpunkt und Organisationsstruktur des indischen 
Entwicklungszentrums 


Wie erwähnt, bildet die (von den Brückenköpfen abgesehen) im indischen Ent- 
wicklungszentrum angesiedelte Einheit Application (neben Vison und Plattform) 
einen von drei Teilen eines Entwicklungsnetzwerkes, in dem eine neue betriebs- 
wirtschaftliche Standardsoftware entwickelt wird. Application fällt innerhalb 
dieses Netzwerkes die Erstellung der obersten Ebene des Softwareprodukts zu. 
Das zu entwickelnde Produkt ist eine internetgestützte Applikation, die auf 
der Basis einer technischen Plattform läuft. Zur Entwicklung wurde das Produkt 
in einen Teil, der die Internatapplikation baut (Application), und einen, der für die 
darunterliegende Plattform zuständig ist (Plattform), geteilt. Ein dritter Teil (Vis7- 
on) erarbeitet die Anforderungen an das Produkt und die grafischen Richtlinien 
der Realisierung. Der von Application in diesem Netzwerk zu leistende Teil be- 
steht somit in der Entwicklung der Internetapplikation, die im wesentlichen aus 
einer Benutzeroberfläche (User Interface - UI) besteht, mit der die Funktionen 
der darunterliegenden Plattform aufgerufen werden können. Die Entwicklung 
der Benutzeroberfläche darf in diesem Zusammenhang allerdings nicht in einem 
grafischen Sinne verstanden werden. Das grafische Design wird von Vision entwor- 
fen und in Form von sogen. „Markups“ als Input an das Entwicklungszentrum in 
Indien gegeben. „Markups“ sind nicht funktionsfähige, grafische Vorlagen, meist 
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in Form von Bildern oder einfachen HTML-Gerüsten, die die wesentlichen Ele- 
mente und deren Position vorgeben. So werden z.B. Vorgaben über die Struktur 
von Menüs und deren Hierarchien von Vision unter Usability-Gesichtspunkten 
entwickelt. Bei Application geht es darauf aufbauend eher darum, die grafischen 
Markups in ein funktionsfähiges Programm umzusetzen, im wesentlichen also 
um die technische Realisierung der grafischen Elemente und die Konfiguration 
und Programmierung der Anbindung der Benutzeroberfläche an die Plattform. 


Insgesamt sind bei Application im indischen Entwicklungszentrum ca. 250 Perso- 
nen beschäftigt. Die Einheit ist gemäß der unterschiedlichen Funktionsbereiche 
des Produkts weiter untergliedert. Das Produkt umfasst 6 größere Funktions- 
bereiche, um die sich je ein eigenes Team kümmert. Neben diesen 6 Funktions- 
bereichen gibt es noch ein paar kleinere unterstützende Bereiche, die sozusagen 
„quer“ zu den Hauptfunktionsbereichen liegen, d.h. die von diesen Bereichen ent- 
wickelten Komponenten werden von allen Funktionsbereichen gleichermaßen 
gebraucht und genutzt”. Je nach Größe der Funktionsbereiche sind diese weiter in 
verschiedene Gruppen (mit spezifischen Unterfunktionen) aufgeteilt. Die Größe 
der Funktionsbereiche streut zwischen 20 und 40 Personen, wobei die kleineren 
unterstützenden Bereiche durchaus auch nur aus 2-3 Personen bestehen können. 
Die folgenden Funktionen und Rollen sind dabei innerhalb von Application an 
der Entwicklung beteiligt: 

Grundsätzlich wird jeder Funktionsbereich von einem Projektmanager betreut, 
bei größeren Bereichen können dies auch mehrere sein, die dann die Verant- 
wortung für einen kleineren Unterbereich tragen. Zusätzlich gibt es für jeden 
Bereich einen sogen. Personalmanager. Die Arbeitsteilung zwischen Projekt- und 
Personalmanager beinhaltet, dass die Projektmanager für die Entwicklung der 
Applikation zuständig sind, also primär einen fachlichen Schwerpunkt haben, 
wohingegen die Personalmanager die Personalverantwortung und -entwicklung 
für ihren Bereich wahrnehmen. 

So sind die Personalmanager primär auf den Vorgang der Leistungsbewertung 
und das Setzen von Zielvorgaben für die Beschäftigten fokussiert, was uns im 
nächsten Abschnitt zur Kontrollstruktur bei NovoProd näher beschäftigen wird. 

Die Projektmanager sind hingegen ganz zentral in die Entwicklungsarbeit 
involviert. So leiten sie das Offshore-Team fachlich an und sind für die Entwick- 
lungsarbeiten ihres Funktionsbereiches dem höheren Management gegenüber 


? So gibt es z.B. einen Unterbereich, der einen Druckdialog entwickelt, der von allen Funktions- 
bereichen eingebunden werden kann. 
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verantwortlich. Zudem sind sie trotz aller erwähnten Probleme in Kooperation 
mit dem jeweiligen Brückenkopf auch in die Diskussionsprozesse des Steue- 
rungsgremiums involviert!?. In dieser Funktion diskutiert der Projektmanager 
zentrale Design- und Entwicklungsfragen auf der Ebene des Gesamtproduktes 
und entscheidet mit über die Richtung der weiteren Entwicklung. 

Unterhalb der Ebene der Projekt- und Personalmanager gibt es noch zwei 
Rollen innerhalb der Projektteams, die des fachlichen Leiters und die des Ent- 
wicklers. 

Einem fachlichen Leiter obliegt gewöhnlich die fachliche Führung einer klei- 
neren Zahl von Entwicklern, z.B. des Unterbereiches eines größeren Funktions- 
bereiches der Applikation. Der fachliche Leiter hat aber lediglich eine fachliche 
Vorgesetztenrolle. Es handelt sich bei fachlichen Leitern um Personen mit ca. 3-5 
Jahren Erfahrung innerhalb des Unternehmens, die als fachliche Vorgesetzte die 
Entwickler anleiten und bei etwaigen Problemen helfen. 

Die Rolle des Entwicklers schließlich stellt die Einstiegsposition bei NovoProd 
dar. Die meisten Beschäftigten finden sich daher bei NovoProd auch in dieser 
Rolle. Die Entwickler tragen primär die Entwicklungs- und Testarbeiten. 


Als Teil eines Entwicklungsnetzwerkes - auch wenn es auf modularen Strukturen 
aufbaut - sind die Entwicklungsarbeiten bei Application nicht unabhängig von 
Vorgängen in anderen Teilen des Netzwerkes, sondern bedürfen permanenter 
enger und intensiver Abstimmung. Bei NovoProd sorgt ein spezielles Steuerungs- 
gremium für diese Koordination (siehe auch Kapitel 6.2). 

Das Steuerungsgremium ist damit auch für die innerhalb von Application ablau- 
fenden Arbeitsprozesse von großer Bedeutung, da dort die zentralen Planungen 
und Entscheidungen für die weitere Entwicklung stattfinden. Die kontinuierlich 
laufende Entwicklung des Produkts wird dazu in aufeinanderfolgende Waves ein- 
geteilt. Eine Wave ist ein bestimmter Zeitraum, meist im Umfang von mehreren 
Monaten, für den vom Steuerungsgremium bestimmte Ziele definiert werden. 
In der Regel handelt es sich dabei um eine feste Zahl von Funktionen der Ap- 
plikation, die in der darauffolgenden Wave umgesetzt werden sollen. Die Waves 
unterscheiden sich dabei sowohl in ihrer Länge als auch in der Art der in ihnen zu 
erledigenden Aufgaben. So gibt es Waves, die vornehmlich der Neuentwicklung 
einzelner Komponenten dienen, und wiederum andere, bei denen die Stabilisie- 
rung des erreichten Standes und damit primär Test- und Wartungsaufgaben im 
Zentrum stehen. 


1° Mit allen Hindernissen, die im vorigen Kapitel in dieser Hinsicht erwähnt wurden. 
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Den Auftakt jeder Wave bildet eine Diskussion des Steuerungsgremiums über 
die in der nächsten Wave zu erbringenden Leistungen. Das Steuerungsgremium 
trifft seine Entscheidungen für alle Funktionsbereiche der Applikation separat, 
d.h. jeder Funktionsbereich (auch die unterstützenden Bereiche) hat für eine 
Wave gesonderte Aufgaben, die in der folgenden Phase bearbeitet werden sollen. 

An der Diskussion des Steuerungsgremiums ist der jeweilige Brückenkopf (un- 
ter jeweils unterschiedlich intensiver Mitwirkung des Offshore-Projektmanagers 
und der fachlichen Leiter, siehe Kapitel 6.2) mit KollegInnen aus den anderen 
Bereichen des Entwicklungsnetzwerkes beteiligt. In dieser Diskussion werden 
die Ansprüche und Forderungen der drei beteiligten Bereiche aufeinander ab- 
gestimmt und auf ihre Realisierbarkeit hin überprüft, wie ein fachlicher Leiter 


schildert: 


„Eh, I mean, we have a development in waves within our product. So 
currently a new wave has started. So which means that we will have to plan, 
what we do ... in the new wave. A wave could be, say, for two, two and 
a half months. So now I have to decide with my Plattform counterparts 
in Germany and Vision, what are the deliverables, that we will deliver in 
this new wave. And then, once we have a common standing with other 
stakeholders - then translate this into, eh, how many resources I have in 
my team, how are they loaded, what portion of work can be done by X, 
what is the portion of work, that can be done by Y? Do I need to decommit 
certain things, because I do not have people, you know? So, a new wave 
of development also means, that you also have to parallely maintain or 
stabilize the things, that you have already developed so far. So, that means, 
there has to be a distribution between development and stabilization. So 
finally, you have to see, how best you can, you know, map the required 
resources and the available resources. And basically feel free to actually say 
no to new requirements, just because you don’t have enough people to 


deliver.“ (NI13) 


Sind am Ende dieser Diskussion die Anforderungen für die nächste Entwicklungs- 
phase beschlossen, gelten diese als feste Vorgaben fiir die einzelnen Funktions- 
bereiche. Damit sind dann sowohl die Aufgaben als auch der zeitliche Rahmen 
der nachsten Wave fiir die Teams in Indien gesetzt, wobei der zeitliche Rah- 
men als externe Anforderung des höheren Managements in die Diskussion des 
Steuerungsgremiums eingebracht wird und damit kaum zu beeinflussen ist: 


„We [das Steuerungsgremium - PF] decide, that we should have this broader 
functionality. So, somebody say for example: ‘I want activity management, 
and within activity management I want these ten functionalities.’ So, this 
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is something, that we discuss at senior management. Now from our VP or 
CEO it will come that: ‘all those things, whatever is proposed, we deliver 
by, say, end of May”. So, this is, when our take closes. So, the dates are 
coming from some other side. [...] So, the overall task definition comes 
from top - the sub-functionalities.“ (NI6) 


Wie bereits erläutert wurde, ist Application in erster Linie mit der technischen 
Umsetzung der Benutzeroberfläche der Applikation befasst. Dementsprechend 
bestehen die vom Steuerungsgremium vorgegebenen Arbeitspakete für die nächs- 
te Wave in einer Zahl von zu entwickelnden oder zu verändernden Teilen der 
Oberfläche. Wenn das Steuerungsgremium z.B. die Implementierung einer be- 
stimmten Zahl von Funktionen beschließt, kann bei Application abgesehen wer- 
den, welche Teile der Benutzeroberfläche von diesen Änderungen betroffen sein 
werden. Die Gesamtoberfläche wird dazu bei Application in sogen. Screens zerlegt. 
Ein Screen ist ein begrenzter Teil der grafischen Oberfläche, der eine feste, vorher 
bestimmte Zahl an Funktionalitäten beinhaltet. Letztendlich besteht die Appli- 
kation somit nur aus einer (wachsenden) Zahl von unterschiedlichen Screens, die 
zusammen die Gesamtfunktionalität der Applikation zugänglich machen. 

Wenn daher die Arbeitsaufgaben für die nächste Wave in den Teams von 
Application ankommen, beinhalten sie eine bestimmte Zahl von zu erstellenden 
oder zu verändernden Screens, die es innerhalb des Teams zu verteilen gilt. 


Definition und Zuweisung der Arbeitsaufgaben 


Im vorigen Abschnitt über das globale Entwicklungsnetzwerk bei NovoProd 
wurde bereits erläutert, dass die von NovoProd strategisch intendierte Form der 
Zusammenarbeit zwischen den Standorten bisher, u.a. aufgrund der Personalt- 
luktuation am indischen Standort und das dadurch in den letzten Jahren aufrecht 
erhaltene Erfahrungs- und Wissensgefälle zwischen den deutschen und indischen 
Teams, nicht realisiert wurde. Auch wurde ausgeführt, dass der Grad, zu dem 
die indischen Teams selbst Projektmanagementfunktionen übernehmen, variiert. 
Wenn daher im Folgenden die Form der Aufgabenverteilung innerhalb der indi- 
schen Teams beschrieben wird, wird auf diejenigen Teams Bezug genommen, die 
das Projektmanagement mittlerweile in Eigenregie betreiben, da diese Form der 
Aufgabenorganisation weitestgehend der strategischen Zielstruktur NovoProds 
entspricht. Im Anschluss an die Darstellung wird jedoch darauf zurückzukom- 
men sein, wie sich die Form der Aufgabenverteilung bei den Teams darstellt, 
die noch stärker aus Deutschland von den jeweiligen Brückenköpfen gesteuert 
werden. 
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Bei den Teams, die das Projektmanagement selber von Indien aus erledigen, 
findet die Verteilung der vom Steuerungsgremium für die nächste Phase der 
Entwicklung beschlossenen Arbeitsaufgaben zwischen den für den jeweiligen 
Funktionsbereich Zuständigen statt. 


„So, the dates are coming from some other side. Then we say: ‘ok, we do 
these ten functionalities within our team’. This goes to the project manager. 
And then they decide - this is the developers - who will take up what; who 
will do when, what and so on. So, the developer is involved right after that. 


(NI6) 


In der Regel macht der jeweilige Projektmanager dazu zunächst einen Vorschlag, 
wie er gedenkt, die Aufgaben auf die beteiligten Entwickler aufzuteilen. Dieser 
Vorschlag wird anschließend im Team diskutiert und evtl. an die Wünsche und 
Interessen der Entwickler angepasst. 


„No, usually ... in the team meetings, I make a first proposal. And then I 
pass it on to the team members, and they can say, if it’s ok with them or if 
they want a change. And then we discuss it in a team meeting and make 
the changes, and then everybody is told.“ (NI25) 


Die Diskussion innerhalb des Teams wird bei NovoProd durchaus ernst ge- 
nommen. Dabei ist nicht nur die Verteilung der Arbeitspakete Gegenstand der 
Diskussion, sondern auch der Zuschnitt und die Spezifikationen der Arbeitspa- 
kete werden im Team diskutiert, wie sich in folgender Aussage eines fachlichen 
Leiters zeigt: 


„We encourage people to suggest changes. [...] Because this is research kind 
of things still, right? So, there might be ... whatever comes from top, might 
not be the best. So you have to also go and take a different approach. So, 
always try to think differently as well.“ (NI6) 


Der zitierte Leiter zieht in seiner Aussage einen klaren Zusammenhang zwischen 
der Art der (dem indischen Entwicklungszentrum zugewiesenen) Arbeitsaufga- 
ben und der Form der Verteilung innerhalb des Teams. Da es sich um Forschungs- 
arbeit handele, seien die Anregungen und die individuellen Perspektiven der 
Entwickler wichtige Ressourcen, die bei der Planung der Entwicklung ganz be- 
wusst mit einbezogen werden sollen. Nach Aussagen der Gesprachspartner wird 
die Verteilung der Arbeitsaufgaben daher mit den Teammitgliedern diskutiert 
und nicht einseitig vom Projektmanager vorgenommen. 

Allerdings sollen durch diese offene Art der Aufgabenverteilung nicht nur die 
Ideen der Entwickler in die Planungen einbezogen werden, es soll diesen auch 
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die Möglichkeit geboten werden, auf die Art ihrer Arbeitsaufgaben einzuwirken 
und sich auf bestimmte Aufgaben und damit zusammenhängend auch auf Teile 
der Applikation, spezielle Funktionen, Technologien o.ä. zu spezialisieren. Ein 
Personalmanager formuliert diesen Punkt folgendermaßen: 


„Weil ich habe natürlich - und auch NovoProd als Firma, denke ich - hat 
natürlich auch kein Interesse daran, jetzt jemandem Aufgaben zu geben, die 
er nicht gerne machen möchte, also wo er überhaupt gar nicht motiviert 
ist oder was einfach von der Persönlichkeit her irgendwie nicht passt. Da 
sind wir wieder beim Beispiel, was ich eingangs gebracht habe, dass es 
einfach Leute gibt, die von der Persönlichkeit eher so die ... Analytiker, die 
dann technisch irgendwie an was rumtüfteln und rummachen und sich da 
wirklich (in Anführungszeichen) ins Kämmerchen einschließen am liebsten 
und dann da rauskommen, wenn sie eine Lösung gefunden haben. Und 
dann gibt’s halt wirklich diejenigen, die unheimlich Spaß dran haben, was 
zu präsentieren und sich auch selbst darzustellen irgendwie. Das hängt 


einfach davon ab.“ (NI1) 


Diese strategische Orientierung wird von einem Entwickler bestätigt: 


„So the project manager ensures that: whatever is assigned to you is of your 
interest. ... You know? Because I joined in the year 2005 - so I have a certain 
degree of experience, that I hold. So, considering the experience that I hold 
- he knows, that: ‘if I assign this particular person for this particular task, 
which is not of his interest - it doesn’t make sense’. Because as on this 
day, after 2 years - he would have some experience. He would have some 
expertise in one particular field. So I should ensure that it is, you know, 
of his interest, so that he can contribute maximum. So it’s that way. My 
project manager, he has asked me, saying: ‘what do you want to do?” [...] 
So those questions are frequently asked.“ (NI14) 


Gerade im Vergleich zu ServiceTec erscheint dieses Vorgehen bemerkenswert. 
Bei NovoProd wird nicht versucht, die Beschäftigten möglichst breit zu quali- 
fizieren, um sie flexibel in unterschiedlichsten Bereichen einsetzen zu können. 
Vielmehr sollen sich die Beschäftigten auf einzelne Bereiche, die sie interessieren, 
spezialisieren und entsprechend „tiefe“ Erfahrungen in dem Bereich sammeln: 


„Over a period of a few years now we have specialists in most areas. [...] 
So initially, they will be given simple tasks. And then you/ll see, how they 
shape up: how much interest a person is taking, how much he has learned. 
Then based on that, he might be given more complex tasks.“ (NI28) 


Daher unternimmt man bei NovoProd auch keine Versuche, die Beschäftig- 
ten zwischen Teams oder gar Projekten zu rotieren. Angestrebt ist eher eine 
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Stabilität der Teams, die Spezialisierung ermöglicht und fördert. In diesem Un- 
terschied spiegelt sich nach Aussage des folgenden Interviewpartners auch ganz 
grundsätzlich der Unterschied zwischen IT-Dienstleistungsunternehmen und 
Produktherstellern: 


»At least in NovoProd it’s ... that’s how it works. Because in a product’s 
team it’s usually not possible for a person to come for two months’ work 
and then go on to a different project. It is true in service industries, eh... 
My friends are in service industries, they keep moving around the projects. 
They have a domain ... at a large, that, ok, I am working on insurance 
domain. But then they keep switching between projects, ok? But for us, it’s 
like, we have a domain, we have a product, which is going to come out in 
the next two years. And hence, everybody spends time on that product for 
two years and so on.“ (NI20) 


Die Verteilung der Arbeitsaufgaben wird bei NovoProd unter erhöhten Mitspra- 
chemöglichkeiten der Entwickler in einem Teammeeting durchgeführt. Dabei 
werden die Beschäftigten auf der einen Seite ermuntert, sich in bestimmten 
Bereichen zu spezialisieren, und andererseits wird bei der Verteilung der Arbeits- 
aufgaben auf diese Spezialisierungen Rücksicht genommen, wie der im Folgenden 
zitierte Gesprächspartner noch einmal zusammenfassend bestätigt: 


„What we do at the beginning of any development cycle is: usually we list 
down all the tasks, that need to be done, and then we identify people, who 
are good at certain things. So somebody is good at ... working on some 
areas. Then we distribute this task - and this is usually done in a team 
meeting. So, everybody, all the developers, everybody is involved in that 
process.“ (NI28) 


Diese Form der Aufgabenverteilung mit ihren erhöhten Mitsprachemöglichkeiten 
und der gewünschten fachlichen Spezialisierung zielt darauf ab, die Entwickler 
zunehmend zu befähigen, die ihnen zugewiesenen Arbeitsaufgaben selbstständig 
zu erledigen und den Bedarf an detaillierter Spezifizierung der Arbeitsschritte und 
konkreter inhaltlicher Anleitung zu reduzieren. Diese strategische Orientierung 
NovoProds zeigt sich auch ganz deutlich, wenn die in diesem Verfahren den 
Entwicklern zugewiesenen Arbeitsaufgaben näher betrachtet werden. 
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Charakter der Arbeitsaufgaben 


Wie erwähnt, bestehen Arbeitspakete bei Application im wesentlichen aus so- 
gen. Screens, also Ausschnitten der Oberfläche, die einen bestimmten Funkti- 
onsumfang beinhalten. Für die Entwicklung der Benutzeroberflächen können 
die Entwickler bei NovoProd auf firmeninterne Tools zurückgreifen, die ihnen 
einen Teil der manuellen Programmierarbeit abnehmen, indem sie es erleich- 
tern, die einzelnen Elemente - teilweise per drag & drop - zu erstellen und zu 
konfigurieren: 


„Es gibt da mehrere Tools, die wir haben, also mehrere Programmierum- 
gebungen eigentlich im Endeffekt, [...] wo eigentlich dann, sagen wir mal, 
weitestgehend bestimmte UI-Elemente konfiguriert werden, bestimmte 
Screens, sagen wir mal, bestimmte Standard-Screens. [...] Und für solche 
Standardaufgaben oder Standardprozesse gibt es natürlich auch, sagen wir 
mal so, Standardelemente, ne? Und wie so ein Screen aussieht - das kann 
man konfigurieren mit diesem Tool.“ (NI1) 


Auf den ersten Blick scheinen die dem indischen Entwicklungszentrum zuge- 
wiesenen Tätigkeiten - z.B. im Vergleich zum Plattform-Teil - damit weniger 
komplex und anspruchsvoll zu sein. Doch darf man sich die Arbeit, die im indi- 
schen Entwicklungszentrum geleistet wird, keinesfalls als ein unkompliziertes 
„Zusammenklicken“ der von der Plattform bereitgestellten Funktionen vorstel- 
len. 

Denn erstens sind diese Tools in ihrem Funktionsumfang nicht umfassend. 
Sie erleichtern zwar bestimmte Standardoperationen, im Großteil der Fälle und 
für spezielle Funktionen ist es aber nach wie vor nötig, Programmierungen per 
Hand vorzunehmen. Daher ist ein tiefes technisches Verständnis der genutzten 
Technologien und Programmiersprachen für die Entwickler von entscheidender 
Bedeutung, zumal die zu entwickelnde Applikation technisch sehr anspruchsvoll 
ist: 


„Damit [mit firmeninternen Tools - PF] lässt sich aber ein UI nicht entwi- 
ckeln in dem Sinne, dass ich dann nachher alle Funktionen, die ich abbilden 
möchte, abbilden kann, und vor allem mit allen Spezialitäten, weil es gibt 
ja nun wirklich sehr komplizierte Elemente und sehr komplizierte Funk- 
tionalitat und da muss ich schon programmieren, und da gibt es dann auch 
andere Entwicklungsumgebungen, da haben wir das Eclipse von Java, das 
ist dann Java-Entwicklung, das ist wirklich hohe Java-Entwicklung, das 
heißt, die Leute müssen wirklich eine gute Ausbildung haben in Java.“ 


(NN) 
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Zweitens ist betriebswirtschaftliches Wissen über die abzubildenden Geschäfts- 
prozesse und deren technischer Realisierung erforderlich. Zwar beinhaltet die 
von Plattform entwickelte Plattform die wesentlichen funktionalen Grundlagen 
der Applikation, und dementsprechend sind die Beschäftigten in diesem Teil des 
Entwicklungsnetzwerkes auch primär mit der „Logik“ der von der Applikation 
abzubildenden Geschäftsprozesse und den betriebswirtschaftlichen Grundlagen 
befasst. Dies bedeutet jedoch nicht, dass sich die Beschäftigten bei Application 
ausschließlich auf technische Fragen der Realisierung konzentrieren könnten, 
wie der bereits zitierte Development Manager erläutert: 


„Und dann Logik - das ist nämlich, was man auch nicht vergessen darf, 
das ist auch Businesslogik, also man kann es nicht ganz trennen, man 
kann nicht einfach sagen, ok, die Leute hier konfigurieren nur Uls, das ist 
eine relativ stupide Arbeit, das könnte man vielleicht meinen oder diesen 
Eindruck gewinnen, das ist aber nicht der Fall.“ (NI1) 


Der Grund dafür ist der Umstand, dass die Plattform zwar grundsätzlich alle 
nötigen Funktionen der Applikation enthält, jedoch nicht immer in der nötigen 
Form. So können z.B. Elemente unterschiedlicher Funktionen in einer spezifi- 
schen Kombination erforderlich sein, die in dieser Form jedoch nicht von der 
Plattform bereitgestellt werden. Für solche Fälle wird innerhalb des Steuerungs- 
gremiums häufig beschlossen, diese Funktionen nicht dadurch bereitzustellen, 
dass eine Erweiterung der Plattform entwickelt wird. Statt dessen werden sie von 
Application realisiert, indem ein separates Objekt zwischen Plattform und UI 
entwickelt wird, das die nötigen Informationen aus der Plattform extrahiert und 
in die vom UI benötigte Form umwandelt und anschließend an das UI weitergibt. 
Diese Entwicklung setzt dementsprechend auch Kenntnisse der zugrundeliegen- 
den Geschäftsprozesse im indischen Teil des Entwicklungsnetzwerkes voraus: 


„Also es ist teilweise so, dass man einfach diese darunter liegenden Busines- 
sobjekte, die den Hauptteil Businesslogik beinhalten, dass man die nicht so 
ohne weiteres einfach konsumieren kann für ein UI. Und dann muss ich 
so eine Art Zwischenobjekt bauen, also so eine Art Schicht dazwischen, 
die mir hilft, meine Prozesse über das UI besser darzustellen letzten En- 
des, und das ist auch noch einmal ein Teil von Businesslogik, Ablauflogik, 
Prozesslogik.“ (NI1) 


Drittens sei an dieser Stelle schließlich daran erinnert, dass es sich auch beim indi- 
schen Entwicklungszentrum um einen Teil der Forschungs- und Entwicklungs- 
abteilung handelt. Das entwickelte Produkt ist ein gänzlich neues im Portfolio 
von NovoProd. Daher kann im indischen Entwicklungszentrum nur begrenzt 


Betriebliche Kontrollstrategien bei NovoProd 197 


auf bereits gemachte Erfahrungen zurückgegriffen werden, was die Entwickler 
permanent zu Improvisationen zwingt: 


„So, we are learning, in fact, my project is considered a research project, 
so it’s very new and we encounter problems every single day, every single 
hour and Ithink, most of my tasks have been evolving around problem 
investigation, rather than constructive development. So, whenever we 
encounter a problem, I think, I always learned better, how to resolve 
problems being at NovoProd, doing this work.“ (NI21) 


Diese Tendenz wird bei Application noch dadurch verstärkt, dass sich bei „ver- 
teilter Entwicklung“ nicht nur der eigene Teil der Applikation, sondern alle 
Komponenten in paralleler Weiterentwicklung befinden. Trotz der formell klar 
scheinenden Aufteilung der Entwicklung zwischen Vision, Plattform und Applica- 
tion bestehen erhebliche Interdependenzen zwischen den Teilen. So beeinflussen 
Veränderungen an den grafischen Vorgaben oder den von Vision erarbeiteten 
Anforderungen des Produktes ganz erheblich die weitere Entwicklung sowohl 
bei Plattform als auch bei Application. Ebenso verändern Änderungen an der 
Architektur der Plattform auch die Art und Weise, in der diese Funktionen von 
Application in die Benutzeroberfläche eingebunden werden können. Durch diese 
dynamischen Interdependenzen zwischen den Modulen erwachsen also auch 
ganz eigene Unwägbarkeiten, die von den Entwicklern bei Application Flexibili- 
tät erfordern, mit der auf externe Störungen der Entwicklungsarbeiten reagiert 
werden muss: 


„There is a lot of the dependencies. And if something goes wrong, your 
project plan goes for toss. And it happens very frequently now. So you have 
to be always involved in something else, some thing or the other.“ (NI6) 


Die Entwicklung der Oberfläche des Produktes im indischen Teil des Entwick- 
lungsnetzwerkes ist demnach ein sehr komplexer Vorgang, der sowohl hohe 
fachliche und qualifikatorische Ansprüche an die Entwickler stellt, als auch 
diverse Unwägbarkeiten des Entwicklungsprozesses aufgrund der hohen Interde- 
pendenzen innerhalb des Entwicklungsnetzwerkes birgt. Ein Personalmanager 
charakterisiert die vom indischen Entwicklungsteam wahrgenommenen Aufga- 
ben dementsprechend wie folgt: 


„Also es ist schon, also man kann es nicht so einfach trennen und sagen, 
ok, die [deutschen Beschäftigten in Vision und Plattform - PF] machen die 
ganze Businesslogik und all den fancy stuff und das Interessante - und in 
Indien, ja, da machen sie sowieso nur Uls und eigentlich ist das Risiko, da 
irgendwas falsch zu machen, relativ gering.“ (NI1) 
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Die spezifische strategische Orientierung NovoProds zeigt sich nun darin, dass 
auch im indischen Entwicklungszentrum nicht versucht wird, die Komplexität 
der Arbeitsaufgaben durch eine erhöhte Arbeitsteilung und Fragmentierung in 
separate und kurztaktige Arbeitspakete für die Entwickler zu reduzieren. Viel- 
mehr werden integrierte Arbeitsaufgaben verteilt. In Kapitel 5.3.1 (6. 96) wurde 
der Software-Lifecycle erwähnt, der aus den aufeinanderfolgenden Phasen An- 
forderungsanalyse, Design, technische Umsetzung, Test, und Wartung besteht, 
und mit dem gewöhnlich die Phasen der Softwareentwicklung beschrieben wer- 
den. War es für ServiceTec typisch, dass diese Phasen sowohl regional als auch 
innerhalb der Teams arbeitsteilig behandelt wurden, und die Entwickler auch 
einzelne Phasen des Lifecycles unabhängig von den anderen bearbeiten, so wird 
bei NovoProd sichergestellt, dass jeder Entwickler die ihm zugewiesenen Screens 
durch möglichst alle Phasen begleitet. Aufgrund der Arbeitsteilung im Entwick- 
lungsnetzwerk sind die Entwickler bei Application zwar von der grundsätzlichen 
Anforderungsanalyse, die von Vision erledigt wird, weitgehend ausgeschlossen, 
jedoch sollen die restlichen Phasen von jedem Entwickler bearbeitet werden, wie 
ein fachlicher Leiter ausführt: 


„Ok, and each screen would entail, you know, different tasks: The design, 
the specification, the design and the implementation and the testing. So for 
each screen all these tasks would be performed by the developer.“ (NI13) 


Die Übertragung eines Screens in die Verantwortung eines Entwicklers bedeutet 
damit, dass er für den vollen Prozess der Entwicklung dieses Screens verantwort- 
lich ist. Eine Arbeitsteilung zwischen den einzelnen Arbeitsschritten findet bei 
NovoProd nicht statt. Statt dessen sollen die Entwickler den von ihnen geschrie- 
benen Teil der Applikation als ihren Teil begreifen, den sie durch den vollen 
Entwicklungszyklus begleiten und mit dem sie sich auch identifizieren sollen. 
Ein Projektmanager formuliert diesen Umstand folgendermaßen: 


„I have - I make it a point that I don’t change the code that they have written. 
[...] Even if I have to change, I would ... I mean, Pd not change any most 
of the times. But if they’re on vacations suddenly, I do not have an option 
other than to fix something. But otherwise it’s a feedback that I give - and 
then I give it in some written format, some mail or something. And then 
they change it. [...] So - because codes are something you’re emotionally 
att... - if you are a developer, then you get emotionally attached to the code 
you have written.“ (NI7) 


Und so finden sich auch Statements von Entwicklern, dass sie sich persönlich für 
„Ihre“ Screens verantwortlich fühlen und sich mit diesen so stark identifizieren, 
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dass sie sogar Überstunden in Kauf nehmen, um gute Ergebnisse zu erzielen. Ein 
Entwickler erklärt: 


„Some people, they do appreciate working late, but if I don’t, I don’t and 
nobody questions me about it, so it works fine for me to leave at five. And, 
eh, nobody has the right to ask me to stay late. Eh, in an emergency, yes, 
when things are really bad or if something is going wrong, I myself would 
love to stay back, because, what I am working on is after all my baby and I 
would want to see it through.“ (NI21) 


Es wird also bei NovoProd nicht versucht, die grundsätzlich als sehr komplex 
charakterisierten Arbeitsaufgaben durch eine starke Fragmentierung und Vorspe- 
zifikation ihrer Komplexität zu berauben. Vielmehr wird die Komplexität der Ent- 
wicklung an die Entwickler weitergegeben, indem sie neben dem Entwicklungs- 
auch den Planungsprozess für die ihnen zugewiesenen Screens selber ausführen 
und verantworten und somit die genannten Unwägbarkeiten der Entwicklungs- 
prozesse selbstorganisiert bearbeiten sollen. Für die Entwickler bedeutet dies 
auch erhöhte Kooperationsanforderungen, da im Laufe der Entwicklung enge 
Abstimmungen mit anderen Teilen des Entwicklungsnetzwerkes nötig sind, die 
bei NovoProd auf Entwickler-Ebene stattfinden sollen. Dies wird im folgenden 
Abschnitt zu den Kooperationsbeziehungen noch genauer behandelt. 

Da Arbeitsaufgaben bei NovoProd grundsätzlich alle Phasen der Entwicklung 
für einen Screen beinhalten, bildet ein Screen auch die Untergrenze des Umfangs 
der verteilten Arbeitsaufgaben: 


„One particular screen would be the responsibility of one developer only. 
So, multiple people will not work on that screen.“ (NI13) 


Es ist jedoch eher selten, dass ein Entwickler lediglich einen Screen während einer 
Wave zu bearbeiten hat. Zumeist handelt es sich um mehrere. 


„Yes, eh, a typical project plan would include, like I said - we decide on 
x-number of screens. These x-screens would be probably ... equally divided 
among the four developers, that are there.“ (NI13) 


Wie viele Screens ein Entwickler jeweils zur Bearbeitung bekommt, richtet sich 
dabei sowohl nach dem Komplexitätsgrad des Screens als auch nach der Erfahrung 
und der Leistungsfähigkeit des Entwicklers. 


„It depends really on the complexities of the tasks. There are some tasks 
- there is this one task, which is very complex, and one person can do it. 
Or again there are ten simple tasks, which also can be done by one person.“ 


(NI28) 
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Neue Mitglieder des Teams werden in Bezug auf die Aufgabenverteilung etwas 
anders behandelt als erfahrenere KollegInnen, wie folgender fachlicher Leiter 
erläutert: 


„Over a period of a few years now we have specialists in most areas. And 
then we have these new colleagues, who are joining and they are getting 
trained. So initially they will be given simple tasks. Excuse me. And then 
you ll see, how they shape up: how much interest a person is taking, how 
much he has learned. Then based on that, he might be given more complex 


tasks.“ (NI28) 


Daher werden bei NovoProd meist zahlenmäßig weniger oder weniger komplexe 
Screens an die neuen Entwickler im Team vergeben, während die erfahrenen 
Entwickler mehr oder komplexere Screens erhalten. 


Die hohe Komplexität der Arbeitsaufgaben erschwert auch die zeitliche Be- 
stimmung der zugewiesenen Arbeitsaufgaben. Die Schätzung der benötigten 
Zeiträume zur Entwicklung eines Screens stellt bei NovoProd für die Projektma- 
nager keine triviale Angelegenheit dar. Da es sich um ein neues Produkt und ein 
neues Setup handelt, gab es am Anfang der Entwicklung keine Erfahrungen, auf 
die gebaut werden konnte und auch firmenweit für andere Bereiche entwickelte 
Richtlinien zur Terminierung von Arbeitsaufgaben waren nicht anwendbar. Statt 
dessen wurde und wird im indischen Entwicklungszentrum parallel an eigenen 
Richtlinien gearbeitet, die sich jedoch nur nach und nach mit den gemachten 
Erfahrungen entwickeln: 


„That’s mainly from our experience. In most of NovoProd naturally there 
are guidelines for deciding that. But because this is a new product and we 
are working on new technology, we are really deviating from all those 
guidelines. So, while we are making this product, we are also ... defining 
these guidelines, that will be for this kind of task. From experience we now 
know, that: if we give this kind of task - with this kind of experience, it 
can be done in this much time.“ (NI28) 


Dementsprechend verlassen sich die Projektmanager auch in erster Linie auf ihre 
eigene Erfahrung: 


„Because I know, the particular task, how much time it takes, because I did 
the reading, [...] I do normally myself on project, so I take myself -I do 
development and do implement. I know, how much time it takes for me.“ 


(NI12) 
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Zum Zeitpunkt der vorliegenden Untersuchung wurden die Screens bei der Ver- 
gabe grob in drei Komplexitätsstufen eingeteilt, für die sich jeweils ein grober 
Zeitrahmen als realistisch erwiesen hat: 


„And we categorize, ok, this is a simple screen, this is a complex screen 
and this is the medium complex screen, ok? So, based on the fields and 
complexity, because I know the set of ... how it exactly will go actually. 
Simple screens is this one, so, the moment, they look at backend and 
frontend, I can say, that it’s a simple screen and is it a complex or medium. 
So it just varies, simple, medium, complex, ok? And for simple two days, 
medium three days and complex ten days. Again the time basis, we know, 
already we know, ok, if we, because it’s a research project, initially we don’t 
know, how many time this takes. But as an experience, I know, how much 
time this kind of thing will take actually. That’s an assumption actually. So, 
we go by assumption initially and then after first phase we know, that what 
exactly it takes the time. Now, we had estimate real, ok, simple, medium, 
complex, divide that actually and give the screens.“ (NI12) 


Doch auch wenn mit der Zeit die Erfahrung innerhalb von Application wächst, 
wie der zitierte Gesprächspartner ausführt, und die Zeitschätzungen damit zuneh- 
mend sicherer werden, bleibt eine gewisse Unsicherheit in der zeitlichen Planung 
stets bestehen. 

So findet erstens durch die hohen Interdependenzen zwischen den Teilen des 
Entwicklungsnetzwerkes eine gegenseitige Beeinflussung der Entwicklung statt. 
Daher können die zeitlichen Planungen bei Application auch durch Probleme in 
anderen Teams beeinflusst und verzögert werden. Gibt es z.B. ein Problem in der 
Plattform für eine bestimmte Funktionalität, so ist der Entwickler der Oberfläche 
für diese Funktionalität auch nicht in der Lage, seinen Screen zu beenden. Dies 
führt einerseits permanent zu internen Konflikten über etwaige Verschiebungen 
der Deadlines, und andererseits auch ganz unmittelbar zu Unregelmäßigkeiten in 
der individuellen Arbeitszeit, wie folgender Entwickler berichtet: 


„We are in the topmost layer of the application - there are two more layers. 
So, usually, when this happens ... you are supposed to wait for the others to 
finish their work. And you are also supposed to wait for other errors to be 
solved before you can do ... But your deadlines don’t move. [...] Then you 
raise an issue with them, and then you wait for them to be solved ... and 
this dependency might ... create some problem. So, if I wait for half a day, 
because I was waiting for someone else’s issue ... and then towards evening 
this issue is solved. Then I have a chance to do it today or do it tomorrow. 
And that depends on, how close to the deadline we are at. And, if it can wait 
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until tomorrow, then yeah, it’s fine - but otherwise your day extends. So, 
there are situations, wherein we have a lot of problems with other stacks, 
and then ... our working hours go beyond eight hours.“ (NI11) 


Durch die hohen Abhängigkeiten innerhalb des Netzwerkes ist die zeitliche 
Planung der Arbeitsaufgaben also immer ein wenig in Bewegung und feste Pla- 
nungen und Termine können durch auftretende Probleme in anderen Bereichen 
plötzlich wieder in Frage gestellt werden. Dies führt gerade gegen Ende der Waves 
häufig zu Problemen, denn auch wenn die Arbeitspakete nicht immer definitiv 
terminiert werden können, bilden die Waves doch klare und vor allem zeitlich 
fixe Termine für die Entwicklung. 

Zweitens hat NovoProd es in den Teams auch mit unterschiedlich erfahrenen 
Entwicklern zu tun. Aufgrund ihrer gewollten Spezialisierung bestehen demnach 
große Unterschiede zwischen den Zeiten, die ein erfahrener und ein unerfahrener 
Entwickler für die Entwicklung eines Screens benötigt. Dieser Umstand wird bei 
der zeitlichen Bemessung der Arbeitsaufgaben zwar berücksichtigt, kann jedoch 
nicht genau bemessen werden: 


„I may code faster because of my experience, but the fresher takes twice 
the time, trice the time. So, according to this, I distribute the task.“ (NI12) 


Ein fachlicher Leiter wird noch deutlicher: 


„So, for an experienced person, I would say: ‘this task can be done in one 
day’; for the less experienced person I would say: ‘this task can be done in 
three days’. If he does it in three days, he is meeting expectations. No one 
will expect him to do it in one day, because we know, he is new.“ (NI28) 


Drittens ist schließlich auch die Komplexität eines Screens im voraus nicht immer 
exakt einzuschatzen. Die Screens werden nicht detailliert vorspezifiziert, sondern 
das genaue Design eines Screens bildet einen wichtigen Teil der Aufgabe eines 
Entwicklers. Dementsprechend zeigen sich manche Probleme auch erst wahrend 
der Bearbeitung und verandern damit den zu kalkulierenden Arbeitsaufwand 
teilweise erheblich, wenn sich vermeintlich leichte Screens aufgrund unvorherge- 
sehener technischer Komplikationen in komplexe verwandeln, wie ein fachlicher 
Leiter aus eigener Erfahrung schildert: 


»When we started off, it was expected, that the Plattform is sufficient to 
realize the screens, but on the way we found, it’s not. Because the capa- 
bilities or the technical restrictions are so many, that you cannot actually 
achieve everything. What happens, if a screen has to correspond to multiple 
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functions? So, this is correctly not possible. So, you need a controller in 
between, which will then talk to multiple functions, but for the screen, you 
are only talking to one controller, so. These kinds of technical limitations 
were bypassed or worked around. [...] Earlier it was thought, that it would 
be enough to develop a screen, it would take two days. But only now we are 
able, you know, fine-tune. Now we can say with a degree of certainty, that 
this is the time, that a person would need to develop that screen.“ (NI13) 


Der folgende Projektmanager findet daher klare Worte fiir die Charakterisierung 
der Zeitschatzungen bei NovoProd. Angesichts der Komplexitat der Tatigkei- 
ten, den möglichen externen Schocks und technischen Störungen, müssten um- 
fangreiche Puffer-Zeiten eingeplant werden, welche die Zeitschätzungen weiter 
erschwerten: 


„It cannot be very hard - as somebody can go on leave or vacation, some- 
thing happens. So everything has to be taken into consideration, buffer 
times need to be taken in consideration. We need, say, 20% percentage - 
actually, PI not say 20 percentage, Pll say 25 or 30 percentage, because at 
times, the technology itself is not supporting, at times something is down. 
Network is down or some other cross feature is not supporting. So we have 
to take into the consideration all that. And actually, it’s not ... it cannot be 
calculated with numbers. It’s just by experience.“ (NI22) 


Dementsprechend grob ist auch die zeitliche Planung bei Application, wie folgen- 
der Gesprachspartner aus seinem Team berichtet: 


„So then, as a project manager, I would have to plan for how much time he 
would require to specify a screen. Then how much time will be required 
to design it, on paper and in the system, and then how much time will be 
required to actually implement it. [...] Ok, so my project plan would be, 
supposed, it’s a three months wave - it would be, that, ok, first month, I 
only do specification and design. And I say, I implement only in the next 
two months. I wouldn’t, I mean - I wouldn’t put in my project plan, saying 
that this [betont] screen will be done by this [betont] day, but it would be 
more or less that, by the first week of May, I would have the specification 
and, eh, design ready for all my screens.“ (NI13) 


Aufgrund der beschriebenen Probleme, die Zeiträume zur Bearbeitung der Screens 
genau zu bestimmen und aufgrund des komplexen Charakters der Entwicklung, 
finden sich bei NovoProd keine eng getakteten Arbeitsaufgaben, wie es fiir 
ServiceTec typisch ist. Je nach den Anforderungen einer Wave variieren die 
Zeitraume, die den Entwicklern zur Bearbeitung ihrer Aufgaben zugestanden 
werden, zwischen mehreren Tagen und mehreren Monaten. 
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Die kürzeren Arbeitsaufgaben finden sich dabei meist in Waves, in denen stark 
auf die Stabilisierung des erreichten Standes der Entwicklung Wert gelegt wird 
und es daher um die Korrektur von Programmierfehlern geht. Dabei korrigieren 
alle Entwickler die Fehler in „ihren“ Screens, d.h. denen, die sie auch selber 
entwickelt haben. Auch in solchen Phasen bleiben die Screens also bei den für sie 
verantwortlichen Entwicklern. 

In Waves hingegen, in denen neue Funktionalitäten implementiert werden, 
wird meist für die gesamte Wave geplant, d.h. die Gesamtzahl der nötigen Screens 
wird am Anfang der Entwicklungsphase zwischen den beteiligten Entwicklern 
aufgeteilt. Je nach Zeitschätzung für die Screens und der Erfahrung der Entwickler 
erhalten diese unterschiedlich viele Screens für die folgende Wave zugewiesen. 
Je nach Komplexität werden dabei für die Screens mehrere Tagen oder mehrere 
Wochen angesetzt. 

Dabei fällt jedoch die Länge der Arbeitsaufgaben nicht mit der Länge der Kon- 
trollzyklen zusammen, wie im nächsten Abschnitt noch genauer diskutiert wird. 
Dennoch stützen, neben den bereits beschriebenen Formen der Aufgabenver- 
teilung, auch die langen Bearbeitungszeiten die These, dass NovoProd versucht, 
eher die Selbstorganisationsfähigkeit der Entwickler bei der Aufgabenbearbei- 
tung zu nutzen, als sich auf enge Vorgaben und klar spezifizierte Arbeitspakete 
zu verlassen. Das zeigt sich auch in der Aussage eines Managers: 


„We never - I mean, we do not assign tasks, which are at least an hour kind 
of work. Like - for today, this is the task; tomorrow, this is the task, you 
know. This is the target for the developing phase, right? So, the target is, 
that in next three months, this is, what we need to deliver. This is the task 
assigned to the group. Now the person is to decide now - he has to ensure, 
that this is delivered. We check weekly, where they stand. We have our 
weekly milestones. So you know, the progress is good enough. Otherwise 
somebody comes after three months and says: ‘I could not deliver’ - then 
you cannot do anything, right? So, we check weekly, but the task always... 
We - I mean, we do not go into this minor - minor details, like, half an hour, 
two hours or four hours. This is taken by the individual. His ownership - 
the topic, he has or she has to ensure, that it’s delivered and so on.“ (NI6) 


Fasst man das bisher tiber die strategische Ausrichtung NovoProds im Bereich 
der Aufgabenorganisation Ausgefiihrte zusammen, so lässt sich feststellen, dass 
NovoProd einen eher permissiven Zugriff auf die Aufgabenorganisation verfolgt. 

Zwar sind die Entwickler im indischen Entwicklungszentrum durch die Ar- 
beitsteilung im Entwicklungsnetzwerk und die zentrale Funktion des Steue- 
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rungsgremiums von strategischen Entscheidungen über die weitere Entwicklung 
weitgehend abgeschnitten, doch auch die Realisierung der Applikation birgt, wie 
gezeigt werden konnte, sehr komplexe Aufgaben, die im indischen Entwicklungs- 
zentrum bearbeitet werden müssen. 

NovoProd setzt dazu strategisch auf die Selbstorganisationsfähigkeiten der 
Beschäftigten. Indikatoren für dieses Vorgehen sind die langen Zeiträume, die 
den Beschäftigten zur Bearbeitung von komplexen (grundsätzlich durch die 
Integration von Spezifikation, Design und Implementierung geprägten) Arbeits- 
aufgaben zugestanden werden. Hinzu kommt die Praxis, die Arbeitspakete nicht 
zentral zuzuweisen, sondern im Rahmen einer Teamdiskussion zu verteilen, 
dabei gezielt die individuellen Interessen der Entwickler zu berücksichtigen und 
sie zu vertiefter Spezialisierung zu animieren. Wie ein roter Faden zieht sich 
die Wertschätzung von individueller Erfahrung, sowohl hinsichtlich der genutz- 
ten Technologien und des Produkts, als auch hinsichtlich des organisatorischen 
Umfeldes durch die Interviews. 


Probleme der Aufgabenorganisation 


Allerdings müssen an dieser Stelle auch die Probleme dieses Vorgehens bei Novo- 
Prod benannt werden. Denn die Implementierung der beschriebenen permissiven 
Strategien im Bereich der Aufgabenorganisation ist keinesfalls voraussetzungslos. 
Wie gezeigt wurde, verlässt sich NovoProd in wichtigen Punkten auf die indivi- 
duelle Erfahrung ihrer Beschäftigten. Allerdings ist die individuelle Erfahrung 
der EntwicklerInnen im indischen Entwicklungszentrum eine kritische Ressour- 
ce. Denn die für Bangalore typischen hohen Fluktuationsraten betreffen auch 
NovoProd. Für die letzten Jahre hat NovoProd zwar mit Raten von knapp 9% 
einen für die indische II-Industrie stark unterdurchschnittlichen Wert vorzu- 
weisen, aber wie bei ServiceTec, fällt die Fluktuation auf den Einstiegsebenen 
wesentlich höher aus als der Durchschnittswert, der über alle Hierarchiestufen 
gebildet wird, suggeriert. Zusätzlich konzentriert sich die Fluktuation in eini- 
gen Teams von NovoProd, so dass es hinsichtlich der gewünschten Stabilität 
der Teams große Unterschiede innerhalb von Application gibt. Im Rahmen die- 
ser Studie wurden Beschäftigte in Teams interviewt, die in den letzten Jahren 
mit stark erhöhten Fluktuationsraten zu kämpfen hatten und die daher zum 
Zeitpunkt der Untersuchung zu großen Teilen aus frisch eingestellten Personen 
mit begrenztem Erfahrungsschatz bestanden. Zudem fanden sich jedoch auch 
Teams, deren Mitglieder teilweise seit Beginn der Entwicklung mit dabei sind 
und daher schon auf mehrjährige Erfahrungen innerhalb von NovoProd zurück- 
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greifen können!!. Da die individuelle Erfahrung der Entwickler bei NovoProd 
eine große Rolle bei der Aufgabenorganisation spielt, kam es nach Aussagen 
der Manager gerade in den Teams, die mit erhöhter Fluktuation zu kämpfen 
hatten, zu Problemen mit der geschilderten Praxis der Aufgabenorganisation, die 
sich in großen Verzögerungen des Ablaufes niederschlugen. Als Resultat wurden 
diese Projekte wieder unter engere Führung durch die Brückenköpfe gestellt, die 
Projektmanagementfunktionen (wieder) auf sich konzentrierten: 


„There is some success, then there are some failures, it depends upon who 
is leading the team here and how is his experience, how confident he is. 
Some projects, it was working here like with me, they are not performing 
good - it [das Projektmanagement - PF] went back to Germany.“ (NI12) 


So unterscheidet sich die Praxis der Aufgabenorganisation in den Teams, die 
mit wenig individueller Erfahrung umgehen müssen, auch von der Praxis in 
den bisher geschilderten, stabileren Teams. Ein Entwickler formuliert diesen 
Umstand, auf den Unterschied zwischen der deutschen Firmenzentrale und dem 
indischen Entwicklungszentrum angesprochen, folgendermaßen: 


„So, they [die deutschen Beschäftigten im Hauptquartier NovoProds - PF] 
become an expert over a period of time and they become masters in that. 
And same thing doesn’t happen in India, because people come, leave, like 
... theyll again come and again leave. This is, like, both ways. Those guys, 
Germans, they cannot give very critical work, because they know, that: 
‘ok, you don’t have the expertise’.“ (NI4) 


So finden sich im indischen Entwicklungszentrum neben den Teams, in denen die 
Entwickler die bisher beschriebenen großen Spielräume bei der Erledigung ihrer 
Arbeitsaufgaben genießen, auch Teams, in denen die Arbeitsaufgaben nach wie 
vor von den deutschen Brückenköpfen definiert und zugewiesen werden und in 
denen den Beschäftigten auf der indischen Seite wesentlich weniger Möglichkeiten 
offen stehen, auf ihre Arbeitsaufgaben Einfluss zu nehmen, wie ein Manager für 
seinen Bereich feststellt: 


„The fundamentals for us - it is: you have to follow the process'?. That’s 
what is being told. And here, the questioning of the process comes into 


11 Im Abschnitt zu den Arbeitsmarktbeziehungen ( Kapitel 6.3.4) wird noch näher darauf einzuge- 
hen sein, warum NovoProd mit niedrigeren Fluktuationsraten konfrontiert ist und wie sie mit 
diesen umgehen. 

12 Mit Prozessen sind in diesem Zusammenhang keine formalen Prozessbeschreibungen gemeint, 
sondern vielmehr direkte Anweisungen für das weitere Vorgehen, die von den Brückenköpfen 
ergehen. 
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picture. ‘Is this a value-add. Can I do something better than this? Why 
can’t I do it this way? Should 1...” And they expect, like: a command - 
execution.“ (NI24) 


Der für dieses Team zuständige Brückenkopf ergänzt: 


„Ja, tatsächlich. Der Takt ist kürzer in Indien. [...] Das liegt an der Projekt- 
leitung und am Management. Wir machen in Indien eine Planung, dass wir, 


oder der zuständige Projektleiter schickt Emails und sagt: ‚Aufgaben für 
diese Woche sind‘.“ (ND4) 


Dieses andere Vorgehen hat Konsequenzen für die Beschäftigten in den indischen 
Teams. Die Verteilung der Arbeitsaufgaben von Deutschland aus berücksich- 
tigt in der Regel weniger individuelle Interessen und nutzt eher den Vorteil, 
dass die neuen Beschäftigten sich noch nicht inhaltlich spezialisiert haben und 
dementsprechend noch flexibel einzusetzen sind: 


„But with these freshers, the advantage I see is: you can move them around. 
With experience, there comes certain rigidity and ... Like, you don’t want 
to do certain task or you do want to. But with a fresher, you have this 
flexibility.“ (NI7) 


Grundsätzlich ändert sich die Form der Arbeitsaufgaben zwar nicht, denn auch 
in diesen Teams handelt es sich um zeitlich recht umfangreiche Aufgaben, die in 
der Entwicklung unterschiedlicher Mengen von Screens bestehen. Jedoch sind 
die deutschen Brückenköpfe sowie die Projektmanager und fachlichen Leiter 
im indischen Entwicklungszentrum in diesen Teams wesentlich stärker in die 
Bearbeitung der Arbeitsaufgaben involviert, indem sie die Screens für die Ent- 
wickler vorspezifizieren und bestimmte Aufgaben übernehmen, die sonst von 
den Entwicklern selbst wahrgenommen werden sollen, wie z.B. das detaillierte 
technische Design eines Screens zu erstellen. Daher entstehen bei diesen Teams 
auch wesentlich höhere Anforderungen an die Kontrollstruktur, genauer: an 
die Art und Weise, in der die Entwickler in diesen Teams angeleitet und bei der 
Bearbeitung überwacht werden. 


„Of course, you have to give a lot of direction as well and, eh ... When 
there are multiple things to be done, then you have to prioritise the work 
for them, otherwise ... they don’t focus out. Compared to people, who are 
experienced - you can’t leave them on their own.“ (NI11) 


Der unterschiedliche Umgang mit den Teams wird in Bezug auf die Kontroll- 
struktur noch ausführlich Thema sein. An dieser Stelle soll daher nur festgestellt 
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werden, dass der erhöhte Aufwand in Bezug auf Anleitung und detaillierte Spezi- 
fizierung der Arbeitsaufgaben diese vereinfacht und damit auch die Attraktivität 
der Arbeit für die Beschäftigten in den indischen Teams reduziert. Viele Entwick- 
ler aus Teams, die das Projektmanagement mittlerweile in Eigenregie betreiben 
und die (aufgrund der Stabilität der Teams) auch viel Einfluss auf ihre Arbeitsauf- 
gaben haben, betonen in den Interviews den herausfordernden und interessanten 
Charakter ihrer Arbeitsaufgaben. Folgender Entwickler wurde zu den Unter- 
schieden zwischen den Arbeitsaufgaben bei NovoProd und seiner vorherigen 
Firma, eines indischen IT-Dienstleisters, befragt: 


„Actually, I get to do something new - and this is the major change. New 
... and I have my ideas as well, which I can implement in some way or the 
other. Even if it’s small modules, not the whole concept of that particular 
product or module. But my part, I can do it my way. [...] Here I can play 
with..., just I am creating my development. I can change the design of my 
code sometimes and then I have done some performance tuning as well. So 
I found, where are the performance leakages and then again I change my 
code. So some new things, I am able to do again. Then integration is also, 
it’s very exciting. When things integrate - and especially, when two such 
things integrate, which are in geographically different locations, at different 
locations. So, at that time it’s very interesting because communication has 
to be very clear, regarding the interfaces and all, right from the starting. 
But later on, what happens is: a little bit here and there it happens, and 
then, you have to access during the time of integration - so that things join 
very easily. And then, when people start using it, we get the issues, those 
issues are good learning, integration issues.“ (NI9) 


Und auch der folgende Gesprächspartner hebt vor allem die große Verantwortung 
für seine Arbeitsaufgaben bei NovoProd hervor: 


„We have the ownership of our work. In other companies we don’t have 
ownership for the work we are doing. It’s basically, somebody is forcing. 
So here, whatever we do comes basically from the senior level management 
in India assigned. And also, it’s not like they are the owner of those tasks. 
They assign the tasks - now, we are ... and we are responsible. So the feeling 
of ownership is there - I mean, that’s why I like it. The work culture is 


good.“ (NI22) 


Bei den Entwicklern in den Teams, die noch - oder teilweise auch wieder - „an 
der kurzen Leine“ gehalten werden, finden sich hingegen häufig Aussagen wie 
die des folgenden Entwicklers, die eher den stark vereinfachten Charakter der in 
diesen Teams verteilten Arbeitsaufgaben vor Augen führen: 
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„So, at times people feel demotivated, ok? The reason being, as I told, lot 
of the things are modelling, ok? So, things are, ... things are easy in a sense, 
at times. So, at times it gets really frustrating for the colleagues as well.“ 


(NI21) 


Diese Unterschiede in der Attraktivitat der Arbeitsaufgaben werden spater noch 
im Zusammenhang mit den Griinden diskutiert, aus denen Beschaftigte zu No- 
voProd wechseln und die Firma wieder verlassen (Kapitel 6.3.4). Doch zunächst 
wird die von NovoProd im indischen Entwicklungszentrum etablierte Kontroll- 
struktur betrachtet. 


6.3.2 Kontrollstruktur 


Die Analyse der Aufgabenorganisation bei NovoProd hat gezeigt, dass der Cha- 
rakter der von Application bearbeiteten Arbeitsaufgaben deren detaillierte Pla- 
nung und zeitliche Terminierung durch den Projektmanager stark erschwert. 
Zudem versucht NovoProd strategisch, möglichst integrierte Arbeitspakete an 
die Entwickler zu geben, die dementsprechend auch zeitlich umfangreich bemes- 
sen sind, und von den Entwicklern - je nach individueller Erfahrung - möglichst 
eigenverantwortlich bearbeitet werden sollen. 


Anleitung und Anweisung 


Diese Art der Aufgabenorganisation geht bei Application einher mit einer Form 
der Kontrollstruktur, die strategisch auf detaillierte und formelle Vorgaben der 
Arbeitsschritte verzichtet und statt dessen darauf setzt, dass die Entwickler mög- 
lichst selbständig versuchen sollen, die Bearbeitung ihrer Arbeitsaufgaben zu 
planen und etwaige Probleme zu lösen, wenngleich diese Zielstruktur auch hier 
nicht in allen Teams gleichermaßen umgesetzt werden konnte. 

Diese strategische Ausrichtung NovoProds hat firmengeschichtlich Kontinui- 
tät. So sei NovoProd nach Aussagen von Vertretern des Qualitätsmanagements 
nie eine sonderlich „process-driven company“ (NI 18,19) gewesen. Vielmehr hätte 
man sich seit jeher stark auf die Beschäftigten und deren Expertise verlassen: 


„Wir sind zwar ein großes Unternehmen, aber Projektsteuerung gab es 
hier ja auch nicht. Irgendwelche Leute waren für irgendwas verantwortlich, 
wer viele kannte, war gut vernetzt und hat viel erfahren. Und so Entwick- 
lungsplane wurden in der Kaffee-Ecke besprochen.[...] Dann gab es halt 
Code-Ownership, bestimmte Leute haben halt Code-Strecken geowned 
und nur die durften auch darin arbeiten und so. Und so war das praktisch 
aufgeteilt.“ (ND1) 
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In der Folge hätten einzelne Teams bei NovoProd häufig auch ganz eigene „impli- 
cit processes“ (NI19) entwickelt, mit denen sie ihre Arbeit strukturierten und 
durchführten: 


„Small groups have evolved their own processes for their own groups.“ 


(NIS) 


Doch im Zuge der Internationalisierung der Produktentwicklung haben Stan- 
dardisierungs- und Formalisierungstendenzen auch bei NovoProd zunehmend 
Einzug gehalten, wie der folgende Gesprächspartner schildert: 


„Aber in dem Moment, wo man halt global entwickeln will, funktioniert 
das halt nicht mehr. Und da haben wir auch erst dann gelernt, okay, viel- 
leicht ist es doch ganz sinnvoll, wir haben eine vernünftige Spezifikation 
für unsere Software. [...] Das man auch mal eine gewisse Disziplin hat, wie 
man so was dann steuert, das ist schon wichtig.“ (ND1) 


Und so werden auch bei NovoProd in den letzten Jahren zunehmend standar- 
disierte Prozessbeschreibungen eingeführt, die den Ablauf der Entwicklung 
strukturieren sollen: 


„We can not afford that you will just do your own thing. We could say 
this 20 years back maybe, but we can’t say this anymore. It is so complex. 
Everything that we do has to be a well defined process, there has to be - 
how do you govern the process? These things must become normal, as the 
usual way of working in NovoProd.“ (NI19) 


Der Grund dafür liegt nach Angaben einer Qualitätsbeauftragten vor allem darin, 
dass informelle Steuerungsformen bei einer großen Zahl von beteiligten Personen, 
die zudem an unterschiedlichen Standorten sitzen, nicht mehr funktionieren. 
Vielmehr sei ein gewisses Maß an Standardisierung nötig, um die Abstimmung 
der beteiligten Personen zu erleichtern: 


„Its about - you have a small team, you have six people, let’s say, in a 
company - you are all sitting here. It doesn’t take me long to say: ‘Hey, just 
tell me what it is and be done with it’. Yeah, it’s a good process - it works! 
I could get up, scream at you - I ask you, what is this. It’s fine - it works 
well, it works very effectively. - Scale it to 60 people. You can still shout 
- if 60 people shout, you can imagine, what chaos it is. 600, 6000, across 
locations? So you have to put some basic standardization in place, right? It 
may be - it can be a format, it can be a tool update ... something. You have 
to bring in those workflows that are required.“ (NI19) 
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In Folge der zunehmenden Standardisierung und Formalisierung sei nach An- 
gaben eines Qualitätsbeauftragten bei NovoProd daher auch das Interesse an 
formalen Prozessmodellen stark gestiegen. Dabei spielt die externe Zertifizierung 
jedoch keine besonders große Rolle (siehe auch Kapitel 2.2). Offiziell zertifiziert 
ist NovoProd lediglich nach ISO 9001. NovoProd strebt es nach Aussagen der 
interviewten Qualitätsbeauftragten auch gar nicht an, sich für andere Modelle 
extern zertifizieren zu lassen. Vielmehr wird versucht, aus den verschiedenen 
Modellen Elemente zu finden, die für die eigene Organisation nützlich sein kön- 
nen (NI 19). Diese gesammelten Prozessbeschreibungen werden innerhalb von 
NovoProd unter einem eigenen Namen, der "NPL"(NovoProd Process Libra- 
ry”) zusammengefasst und firmenweit von einer eigenen Abteilung verwaltet. 
Die NPL ist damit vor allem eine Sammlung von Best-Practices und Versatz- 
stücken aus anderen Prozessmodellen, wie CMMI oder auch Six Sigma, die je 
nach Eignung integriert werden. 

Die in der NPL zusammengefassten Prozesse beinhalten Vorgaben darüber, wie 
bestimmte Entwicklungsschritte ausgeführt werden sollen, d.h. welche Schritte in 
welcher Reihenfolge mit welchen beteiligten Rollen durchlaufen werden müssen. 
Gleichzeitig werden in diesen Prozessmodellen jedoch auch Metriken gebildet, 
mit denen die Ausführung der Prozesse gemessen werden kann. 


„Beides eigentlich, also es sind sowohl Prozesse, die dann eben einen Ent- 
wicklungsprozess oder andere Prozesse eben durchziehen und wer, wann, 
wie informiert werden muss, wo und wie Spezifikationen geschrieben 
werden, wie Dinge geratet werden, welche Dinge eben für ‚change request‘- 
Prozesse gemacht werden etc. Aber umgekehrt eben auch formale Dinge, 
die einfach als Festgrößen abgenommen werden und über die Zeit aufge- 
tragen werden und eben geschaut wird, wie man sich dabei entwickelt.“ 


(ND7) 


Grundsätzlich befindet sich NovoP rod jedoch noch in einem Experimentierstadi- 
um, was die zu implementierenden Prozesse angeht. Der NPL befand sich zum 
Untersuchungszeitpunkt noch im Aufbau, und viele Prozesse wurden noch in 
Pilotprojekten getestet und auf ihre Eignung hin untersucht. So berichtet die 
Qualitätsbeauftragte, dass z.B. die Nutzung von Six Sigma in den Projekten zum 
Untersuchungszeitpunkt getestet wurde, aber noch nicht verpflichtend imple- 
mentiert sei. Vielmehr müssten sich Projekte, die Six Sigma gern probeweise 
implementieren möchten, gezielt darum bewerben und etwaige Mehrkosten 
würden auch auf die Projekte gebucht (NI19). 


13 Name selbstverständlich verändert. 
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Die Internationalisierung der Produktentwicklung wird also auch bei NovoProd 
von einer zunehmenden Standardisierung und Formalisierung begleitet. Doch 
diese Standardisierung und Formalisierung folgt bei NovoProd im Vergleich 
zu ServiceTec einer ganz anderen strategischen Zielsetzung. Im Gegensatz zu 
ServiceTec sollen die Prozessbeschreibungen bei NovoProd nicht primär die 
Abhängigkeit von einzelnen Personen reduzieren, indem die Arbeitsverrichtung 
der Beschäftigten zentral und formal angeleitet und vorgeschrieben wird und 
Handlungsspielräume der Beschäftigten bei der Bearbeitung eingeschränkt wer- 
den. Vielmehr ist den meisten Gesprächspartnern auch im höheren Management 
von NovoProd eine deutliche Skepsis gegenüber einer Anleitung und Anweisung 
der Beschäftigten mittels standardisierter Prozessvorgaben anzumerken. Der 
folgende Brückenkopf fasst die vielfach geäußerten Zweifel zusammen: 


„Auf der einen Seite stellt man fest, dass es sinnvoll ist, solche Dinge [for- 
male Prozesse - PF] zu etablieren, gerade eben in einer größer werdenden 
Organisation, gerade in einer verteilt arbeitenden Organisation. Auf der 
anderen Seite erkennt man eben auch sehr stark immer wieder, wie die 
Dinge an dem eigentlichen Kern dessen, was man damit erreichen wollte, 
vorbeigehen, oder Dinge sich ausnutzen lassen, oder eben formal erfüllt 
werden, aber inhaltlich nicht erfüllt werden. Und es ist sehr schwierig, teil- 
weise dann, sowohl auf der deutschen Seite als auf der indischen Seite eben, 
mit den Leuten zu reden und ihnen klar zu machen, dass an der Stelle das 
so nicht gelebt werden darf, weil ansonsten das Ding insgesamt nicht funk- 
tionieren wird. Und es eben unheimlich schwierig ist und teilweise, meines 
Erachtens, konzeptionell einfach nicht möglich ist, das eigentliche Ziel der 
realen Welt sinnvoll zurück abzubilden auf den KPI [Key Performance 
Indicator - PF] oder den Prozess selber. Also wenn ich die entsprechenden 
Verbesserungen in dem Prozess oder in den Messgrößen kennen würde, mit 
denen man das besser erfassen würde, dann würde ich das vorschlagen. Das 
ist nicht das Problem. Das würde mir auch kein Mensch übelnehmen, im 
Gegenteil, wahrscheinlich würden mir die Füße dafür geküsst werden. Aber 
es ist halt sehr schwierig, sinnvollere Dinge zu finden. Und umgekehrt, 
je mehr man eben aufsattelt, desto größer wird das Bürokratiemonster, 
was dadurch natürlich entsteht. Insofern ist da natürlich auch eine gewisse 
Grenze gegeben, was man eben formalisieren kann.“ (ND7) 


Die Skepsis dieses Brückenkopfes bezieht sich damit vor allem darauf, dass ein 
formalisiertes Prozessmodell oder daraus abgeleitete Kennziffern immer Abstrak- 
tionen vom konkreten Projektverlauf sind und die Kenngrößen und Vorgaben 
der Modelle nicht notwendigerweise mit den realen Notwendigkeiten des Projek- 
tes übereinstimmen müssen. Ganz deutlich zeigt sich in diesem Statement auch 
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die Befürchtung, zuviel formelle Vorgaben, zuviel bürokratische Steuerung - das 
„Bürokratiemonster“ - könne die Entwicklung eher gefährden und hemmen als 
fördern. Dabei spielt auch wieder die Art der bei NovoProd geleisteten Arbeit 
eine zentrale Rolle, wie folgende Aussage der Qualitätsbeauftragten zeigt: 


„You know, like Itold you, this is a research group and we are proving, we 
are trying to prove some very new technologies to the world! So, there is a 
lot of this R&D mind-set, that is there. That, you know, we’ll be creative, 
Pll keep trying, third time something works. So, in that situation, you 
cannot put a high overhead of process, because the challenge there is to 
make it work first, yeah? I don’t want to be a burden. So we do try to put 
some bare minimum checks and balances, that is required. But not - if you 
ask me, are you 100% compliant? No, we are not!“ (NI19 - Hervorhebung 
des Autors) 


Die Tatsache, dass im Entwicklungszentrum in Indien ein neues Produkt ent- 
wickelt wird, dass es sich damit also bei der geleisteten Arbeit auch um For- 
schungsarbeit handelt, hat also nach Aussage der Qualitatsbeauftragten auch 
Konsequenzen fiir die Gestaltung der Kontrollstruktur. Wie bereits im Abschnitt 
zur Aufgabenorganisation ausführlich ausgeführt, birgt die Entwicklung des neu- 
en Produkts viele Unwägbarkeiten für das Projektmanagement bei NovoProd. 
So entstehen viele Probleme im Arbeitsablauf oft erst während der Entwicklung 
und durch die Interaktion zwischen den verschiedenen Teilen des Entwicklungs- 
netzwerkes. Die zeitliche Planung und die klare Definition der Arbeitsaufgaben 
wird dadurch deutlich erschwert und nötigt Entwickler wie Projektmanager 
stetig zu Improvisation und eigenverantwortlicher Problemlösung. Auf diese 
Anforderungen können standardisierte Prozessmodelle auch keine eindeutige 
Antwort geben. Daher sind die Prozesse bei NovoProd auch lediglich als ein 
grober Rahmen konzipiert, der von einzelnen Abteilungen und Teams flexibel an 
lokale Gegebenheiten angepasst und dadurch firmenweit unterschiedlich „gelebt“ 
wird. So hat auch das indische Entwicklungszentrum Prozesse der NPL für seine 
eigenen Ziele etwas modifiziert: 


„Ihe approach we took here, was slightly different. There is a standard, 
that was there across NovoProd. There is something called NPL. We didn’t 
take it as it is- we tailored it slightly within our group. Because it works 
differently in our development and then we said: ‘Ok, we see that some 
teams say: This is not, what fits me, may be I use this tool, blablabla.’ We 
have those little tailorings added now.“ (NI19) 
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Zentrales Merkmal der Prozessorientierung bei NovoProd ist dabei, dass die 
implementierten Prozessmodelle ganz explizit nicht dazu führen sollen, dass 
die Entwickler von den Prozessbeschreibungen gegängelt werden, indem diese 
Prozesse bis ins Detail die Arbeitsverrichtung vorschreiben und anweisen: 


„l would say, you have to take a part in between. There are still work fra- 
meworks, that you can put in place - and some place, where you have to let 
it to the creativity. [...] So, I would say, there should be - any organization, 
if they think correctly, should be able to put some broad framework, in 
which people can operate. But within that - yes, you should give flexibility, 
you should not bring in the bureaucracy angle. Keep that to the minimum!“ 


(NI19) 


Die Kreativität der Entwickler und deren eigenverantwortliches, problemlösen- 
des Handeln genießt als wichtige Ressource bei NovoProd trotz des geschilderten 
Standardisierungsdruckes nach wie vor große Wertschätzung und wird für den 
Erfolg der Entwicklung auch als kritisch angesehen. Obwohl in den letzten Jah- 
ren also unbestreitbar der Umfang der formalen Vorschriften und Regelungen bei 
NovoProd zugenommen hat, ist der Arbeitsprozess gegenwärtig noch wesentlich 
vom „alten“, in der Firmentradition stehenden Vorgehen dominiert, wie die 
beiden Qualitätsbeauftragten gleichermaßen konstatieren: 


„In NovoProd it still works a lot through personal contacts and networks. 
[...] I told you in the beginning, I love NovoProd as a company, I really 
like it. This is the culture of NovoProd. But of course as a professional, as a 
quality professional - it is...“ 


[,,-.a nightmare“, ergänzt der Interviewer und alle lachen] (NI18) 
Auch die folgende Aussage der anderen Qualitatsbeauftragten stiitzt diese These: 


»NovoProd is a more people-driven company, I would say. They still like 
to catch the experts and get things threshed out. We still work in that mode, 
too. Of course, there are guidelines, but I wouldn’t say, we are 100 percent - 
everything is available. It’s a whole load of information - but here, it’s a 
highly people oriented company, very networking kind of. So, you know 
me as an expert, so we just take the code to him, and he’ll just go over it. We 
still follow that - though we are such a huge company, those practices still 
exist. Initially, when I came, I was equally surprised that - ‘I go to him every 
time’. [...] But now I am beginning to realize, that the people networking 
is of more highly importance than anything else actually here.“(NI19) 
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Die beiden zitierten Aussagen reissen schon Zusammenhänge zwischen dieser 
Form der Kontrollstruktur und anderen Aktivitätsfeldern (wie Arbeitsmarktbe- 
ziehungen) an, die später diskutiert werden. An dieser Stelle ist jedoch zunächst 
festzuhalten, dass formelle und detaillierte Formen der Anweisung und Anleitung 
des Arbeitsprozesses mittels standardisierter Prozessmodelle, wie sie bei Service- 
Tec prägend waren, bei NovoProd für die Charakterisierung der Kontrollstruktur 
nicht zentral sind. Vielmehr sollen die Entwickler ihren Arbeitsprozess mög- 
lichst selbständig organisieren und planen. Dazu werden ihnen, wie der Abschnitt 
über Aufgabenorganisation gezeigt hat, möglichst integrierte und langfristige 
Arbeitsaufgaben zugeteilt und diese nicht kleinteilig heruntergebrochen. 


Zentrale Elemente der Anweisung und Anleitung im Arbeitsprozess sind bei 
NovoProd auf der einen Seite die Vorgaben und Standards, die sich aus der Ge- 
samtarchitektur und dem Design des zu entwickelnden Produkts ergeben, und auf 
der anderen Seite die jeweiligen fachlichen Vorgesetzten, die den Arbeitsprozess 
begleiten und Hilfestellung bei Fragen und Problemen leisten. 

Da es sich bei dem zu entwickelnden Produkt um eine Applikation handelt, 
die bestehende Funktionen einer zugrundeliegenden Plattform einbindet, sind 
die Funktionen der Plattform für die Entwicklung der UI’s insofern externe 
Vorgaben, als sie nur in einer bestimmten Weise eingebunden werden können. 
Hinzu kommen vom Solution Management definierte Standards hinsichtlich 
der grafischen Umsetzung der UI’s. Diese beinhalten Vorgaben zu Design und 
Usability der Applikation. 

Diese Standards werden in umfangreichen sogen. „Cookbooks“ und „Style- 
Guides“ zusammengestellt und den Entwicklern zur Verfügung gestellt. Sie gelten 
weltweit für alle an der Entwicklung beteiligten Teams und sind für die Entwick- 
ler bei Application daher nicht zu verändern. Sie fungieren damit als die Arbeit 
der Entwickler anleitende „Frameworks“ der Entwicklung. Allerdings enthalten 
sie in erster Linie Vorgaben über das Ergebnis der Entwicklung, also darüber, wie 
die zu entwickelnden Screens am Ende aussehen und mit der Plattform kommuni- 
zieren sollen. Für dieses Ergebnis werden auch Checklisten mitgeliefert, anhand 
derer die Entwickler den von ihnen erstellten Code auf seine Standardkonformi- 
tät hin überprüfen können. 


„So, you always have a guideline and you have a checklist. So, when you 
start your work, you are sure, that you have read the guideline and you 
follow it. And if you fail there, then in, the checklist will anyway point 
it out - and then you have to rework. So, there is a guideline, there is a 
checklist and in between you do your work.“ (NI11) 
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Nach Angaben der Gesprächspartner leiden diese Standards mittlerweile an 
einem übermäßigem Umfang, was ihre Wirksamkeit im Arbeitsprozess eher 
schwächt als stärkt. Ein Entwickler beschreibt die Situation wie folgt: 


„Also es gibt zum Beispiel einen Standard, das ist der sogenannte Style- 
Guide, der beschreibt, der beschäftigt sich damit, wie ein UI aussehen muss. 
Das ist ein Dokument, das hat, ich weiß es nicht, ungefähr 1000 Seiten. Und 
von diesen Dingern gibt’s ein paar, die für uns mehr oder weniger relevant 
sind. Also es ist sehr, sehr schwierig für die Entwickler, alle Standards zu 
kennen und zu befolgen, weil es einfach so unglaublich viele sind.“ (ND4) 


Die bei NovoProd definierten Standards in Hinblick auf die technischen Spezifi- 
kationen der Applikation haben nach Angaben des Entwicklers mit der Zeit ein 
Ausmaß erreicht, das es für die einzelnen Entwickler unmöglich macht, sie alle in 
ihrer Arbeit zu vergegenwärtigen und zu befolgen. Da es sich allerdings in dieser 
Form lediglich um ex-post Standards handelt, ist dies für die Entwickler nicht 
besonders problematisch, da die Standards auch nur bei Bedarf befolgt werden 
können. D.h. wenn ein Entwickler mit einem bestimmten Problem konfrontiert 
ist, kann er sich die zu diesem Problem gehörigen Vorgaben punktuell aneignen. 


Diese Form der Produktstandardisierung betrifft daher auch nur indirekt den 
Arbeitsprozess, sondern eher die Arbeitsgrundlage, auf der die Entwickler ope- 
rieren. Konkrete Anweisungen hinsichtlich des Vorgehens bei der Entwicklung 
lassen sich aus diesen Standards nicht gewinnen: 


„We know the guidelines. So there is no point in instructing something, 
and ... There is no instruction based manual that we have been given 
[schmunzelnd]. It’s, like: ‘you know what to do, so - go for it. Let’s see!“ 


(NI14) 


Die Relevanz der Guidelines und Standards fiir die Arbeitsverrichtung der Ent- 
wickler wird zudem noch dadurch geschwacht, dass diese selber im Laufe der 
Entwicklung erst entwickelt wurden und sich ebenso in standiger Weiterentwick- 
lung und Veränderung befinden, wie die Applikation, auf die sie bezogen sind. 
Demnach sind die Standards auch noch nicht für alle Gegebenheiten ausreichend 
spezifiziert, wie ein Projektmanager erwähnt: 


„I mean, right now, there are lots of problems in compliance. But then, we 
have some things planned to see, that we can correct all these things. So, we 
have some code inspections and things like that, which are planned. Where 
there are experts, who will go through all these things and try to find out. 
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But it’s not done on a full flatted scale now, because again, as I said: these 
[guidelines - PF] are evolving.“ (NI11) 


Demnach sind die technischen Spezifikationen der Applikationen nicht nur von 
einem mittlerweile unhandlichen Umfang, sondern zudem (da es sich um ein 
neues Produkt handelt) von vorläufigem Charakter. So müssen Entwickler bei 
ihrer Arbeit permanent improvisieren. Wenn z.B. bestimmte Funktionen der 
Plattform verändert werden, ändert sich auch die Schnittstelle zum UI, so dass die 
bestehenden Standards nicht mehr zutreffend sind. Für die Entwickler bedeutet 
dies, dass an diesem Punkt die Anbindung des UI’s an die darunterliegende 
Plattform hergestellt werden muss, auch ohne dass auf fertige Vorgaben rekurriert 
werden kann. 


„And process is an evolving thing. And everyday it’s happening - every 
time it’s changing.“ (NI24) 


Diese Situation gepaart mit einem stetigen Zeitdruck bei nahenden Deadlines 
führt zu einem recht pragmatischen Umgang der Entwickler mit den vorfindli- 
chen Guidelines, wie er sich in der Aussage eines Entwicklers ausdrückt: 


„There is naming convention! But in the, like - if you’re doing development, 
fast track development. And if you’re lost in the development - then at 
times it’s not easy to just look back with all the commitment. NovoProd 
has - in fact, Java has its own naming convention guidelines; NovoProd 
has the naming convention guidelines for example. But most of the times, 
I mean - when you're starting fresh, probably it’s easy. But when you’re 
doing some fast track development, that you have to finish something 
today or tomorrow, then you tend to ignore those things and you tend to 
concentrate on getting things done.“ (NI7) 


Die Standards und Vorgaben hinsichtlich der Architektur und des Designs der Ap- 
plikation geben den Entwicklern also nur einen groben Orientierungsrahmen bei 
der Bearbeitung ihrer Arbeitsaufgaben, indem Eckpunkte des zu entwickelnden 
Screens definiert werden, und dies auch nur eingeschrankt, da sich die Vorgaben 
teilweise im Laufe der Entwicklung verandern und weiterentwickeln. 


Der Prozess der Anweisung und Anleitung der Entwickler im Arbeitsprozess ist 
bei NovoProd daher noch stark mit persönlichen Formen der Kontrolle verbun- 
den. Diese funktioniert primar tiber die jeweiligen Vorgesetzten, die als fachliche 
Autoritat bei Fragen und Problemen mit den zugewiesenen Arbeitsaufgaben 
helfen, Lösungen zu finden. In den meisten Fällen handelt es sich dabei um den 
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für das jeweilige Team zuständigen Projektmanager, in größeren Teams kann 
auch ein fachlicher Leiter diese Funktion für eine kleine Gruppe (3-4 Entwickler) 
innerhalb des Teams übernehmen, wie ein fachlicher Leiter ausführt: 


„Usually, if a colleague has a problem, then he just talks to one of us, who 
is more experienced in this product. We will solve it. And then, if Inow 
still don’t know, I look at the document. So, that’s mainly, what a project 
manager, an architect does. He is supposed to be the expert in that topic. 
So, you are really the first point of contact, if somebody has a technical 
problem or a functional problem.“ (NI28) 


Das strategische Ziel dabei ist, dass die Entwickler ihre Arbeit möglichst selber 
organisieren und planen, der fachliche Leiter sich also zurückhält und nur bei 
Problemen oder sonstigen Fragen der Entwickler eingreift und Hilfestellung 
bietet. Dies beruht auch auf dem Charakter der zu bearbeitenden Aufgaben, die 
ein Komplexitätsniveau aufweisen, das es schwierig macht, klare Vorgaben für 
deren Bearbeitung zu geben: 


„Dazu ist dann die Tätigkeit doch zu anspruchsvoll hier, als dass man 
wirklich so genaue Anweisungen geben könnte.“ (ND7) 


Jedoch lassen sich auch hier innerhalb von Application - wie schon für den Bereich 
der Aufgabenorganisation konstatiert - z.T. erhebliche Unterschiede feststellen, 
inwiefern es den Projektmanagern gelingt, diese Zielstruktur zu realisieren. 

Denn die Fähigkeit, die Arbeitsaufgaben selbständig und weitestgehend in 
Eigenverantwortung zu bearbeiten, hängt gerade angesichts der nur in beschränk- 
tem Maße anwendbaren formalen Vorgaben ganz wesentlich von der Erfahrung 
der Entwickler mit dem zu entwickelnden Produkt und dem organisatorischen 
Umfeld bei NovoProd ab. 


„And then for me, when I joined the project, I didn’t know, what to do, 
how to do. So, the leads helped me out, they told me, this is, how it is to be 
done, For my first screen, my senior wrote a lot of code for me, he showed 
me, that, ok, this is the way, it’s to be done. So, for the first screen I faced a 
lot of problems, because it was new for me and I didn’t understand any, I 
didn’t have any clue as to what was happening, but once I did one controller, 
slowly and slowly I got hold of it and he used to frame me very well, that, 
ok, this is how it happens, this is how you should work. [...] So, sooner 
or later I could get a reasonable grasp of it and today I can independently 
propose the design at least and that’s something good. [lacht] I don’t need 
so much of dependence on others, so I can propose it.“ (NI10) 
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So lässt sich für die untersuchten Teams konstatieren, dass die Beschäftigten in 
den Teams mit höherer Personalfluktuation und einer entsprechend größeren 
Zahl an noch relativ unerfahrenen KollegInnen, nicht nur kleinteiligere Arbeits- 
aufgaben erhalten, sondern dass diese Arbeitsaufgaben von den Leads und Project 
Managern auch wesentlich stärker vorspezifiziert werden müssen. So berichtet 
ein Gesprächspartner aus seinem Team, dass die Mitglieder des Teams „ständig in 
[sein - PF] Büro gerannt“ kämen, und ihn fragen würden, wie sie ein Problem 
lösen sollten, weil sie nicht wüssten, wie vorzugehen sei (NI 26). Der Manager 
müsse in diesem Falle sehr viel Hilfestellung geben und Zusammenhänge der 
Applikation erklären, bis die Entwickler selber eine Lösung entwickeln könnten. 
In den Teams allerdings, die über die letzten Jahre relativ stabil waren und deren 
Beschäftigte daher viel Erfahrung im Umgang mit der Applikation besitzen, 
reduziert sich die Funktion der Anleitung und Anweisung meist darauf, bei 
gravierenden Problemen einzugreifen und Hilfestellung zu geben. Der Großteil 
der Entwickler in diesen Teams plant und organisiert seine Arbeitsaufgaben 
mittlerweile weitgehend selbst. 


Überwachung der Arbeitsabläufe 


Auch wenn NovoProd - sofern das Team erfahren genug ist - versucht, auf detail- 
liertes Anleiten und Anweisen der Entwickler zu verzichten und statt dessen die 
Bearbeitung der Arbeitsaufgaben in die Verantwortung der Beschäftigten legt, 
bedeutet dies nicht, dass der Fortschritt der Arbeit nicht gewissenhaft überwacht 
würde. Denn obwohl die Einschätzung des zeitlichen Umfangs der Arbeitsaufga- 
ben - wie im Kapitel über die Aufgabenorganisation gezeigt - nicht einfach ist, 
gibt es gegenüber dem Steuerungsgremium doch ganz klare zeitliche Deadlines 
für die Gesamtentwicklung, die einzuhalten sind. So werden vom Steuerungsgre- 
mium für alle an der Entwicklung beteiligten Teams die aufeinanderfolgenden 
Waves der Entwicklung definiert. Der Endpunkt einer Wave stellen daher auch 
für Application eine klare Vorgabe dar, die nur sehr schwer aufzuschieben ist. 
Sind daher die Arbeitsaufgaben der Entwickler innerhalb jeder Wave zeitlich 
auch recht grob spezifiziert, so bilden die Enden der Waves feste Termine, zu 
denen die jeweils geplanten Arbeiten erledigt sein müssen. Eine gewissenhafte 
Überwachung der Arbeitsabläufe ist daher für die Projektmanager wichtig, um 
den Stand der Entwicklung jederzeit einschätzen zu können: 


„Exactly. It’s up to them. It’s their task, they have to deliver either way. But 
we do track it very closely, because you cannot accept any delays. Because 
this is revenue for the company.“ (NI6) 
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Für die Überwachung der Arbeitsabläufe sind die fachlichen Vorgesetzten in 
den Teams verantwortlich, also je nach Teamgröße die Projektmanager oder 
fachlichen Leiter. Formell wird der Fortschritt der Arbeiten in allen Teams 
einmal pro Woche in einem Teamtreffen, dem sogen. „Statusmeeting“ von den 
Projektmanagern erhoben. Die Ergebnisse dieser Statusmeetings werden auch an 
das Steuerungsgremium kommuniziert und dort auf übergeordneter Ebene für 
alle beteiligten Teams verfolgt. In den Statusmeetings stellen alle Entwickler vor, 
was sie in der letzten Woche gemacht haben, und sprechen auch etwaige Probleme 
oder offene Fragen an, die anschließend im Team diskutiert werden. Auf diese 
Weise wird der Stand der Projektarbeiten auch für alle beteiligten Entwickler im 
Team transparent gemacht. Einmal die Woche wird der Stand der Projektarbeiten 
damit auf jeden Fall erfasst. 


„We have a weekly status meeting. [...] So we know at the end, where do 
we stand. [...] We define the weekly targets first of all. So, if we have to 
deliver ten by end of, say May - then you have to deliver first two by this 
month, three by next week and ... So, calendar week targets, we will have. 
And then you track against the calendar week target, whether you have 
achieved it or not.“ (NI6) 


In der Praxis sind die Kontrollzyklen jedoch teilweise wesentlich kurztaktiger. 
Die Projektmanager und fachlichen Leiter sind in ihrer Anleitungsfunktion sowie- 
so ständig in engem Kontakt mit den Entwicklern und haben so die Möglichkeit, 
sich informell ein Bild vom Fortgang der Arbeiten zu machen. Wie häufig sich 
die fachlichen Vorgesetzten des Status der Entwicklungsarbeiten vergewissern, 
hängt dabei wieder entscheidend von der Zusammensetzung des Projektteams ab. 
Genau wie die Intensität der Anleitung und Anweisung durch den Vorgesetzten 
bei neuen und unerfahrenen Beschäftigten höher ist, ist auch die Überwachung 
durch den Vorgesetzten bei diesen Beschäftigten zunächst intensiver. Sobald 
die neuen Entwickler jedoch erfahrener werden, wird die Überwachung stetig 
reduziert, wie ein fachlicher Leiter ausführt: 


„Ihe first thing would be: how responsible your manager thinks you are. 
So, no one really likes to be treated as, eh, I mean, if my manager, eh, always 
suspects me, and every day asks me: ‘are you doing your job, are you doing 
your job?’ That’s not something, anybody likes. So, this does not happen 
here. I have worked in three teams with three managers. I worked with 
two Indian managers and one German manager. And the experience always 
has been, that: they will give you a task usually. And the first time, they 
give you a task, they will review it closely. If it’s the first time, they gave 
you a task. But once, you do the task properly - after that no one really 
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bothers you every day. So, somehow it’s up to you also: you have to build 
that trust.“ (NI28) 


Zwar wird bei NovoProd strategisch beabsichtigt, den Verlauf der Projekte in wö- 
chentlichen Treffen zu erheben und die Entwickler möglichst nicht mit kurztak- 
tigen Statusmeldungen zu behelligen, die die individuell auf die Arbeitsaufgaben 
verausgabte Arbeitszeit wird dennoch auf Tagesebene erfasst. Diese Erhebung hat 
aber nicht den formalisierten und feingliederigen Charakter des Vorgehens bei 
Service Tec (vgl. 5.3.2). Wurde bei ServiceTec versucht, durch den Einsatz weitrei- 
chender computergestützter Systeme die Arbeitsverausgabung der Beschäftigten 
teilweise im Minutenbereich zu messen, wird bei NovoProd die Verausgabung 
der Arbeitszeit in „Entwicklertagen“ gemessen. Die Entwickler erfassen ihren 
Arbeitsaufwand selbst und buchen diesen auf die Projekte, in denen sie eingesetzt 
sind, wie ein Manager erläutert: 


„Es gibt natürlich schon ein sehr gutes Projektmanagement. Nur, die Kolle- 
gen erfassen natürlich dann selbst, wie viel Zeit sie mit welchen Projekttä- 
tigkeiten verbracht haben. Das wird praktisch auf einer Tagesbasis erfasst. 
Selbst ich erfasse das. Das ist auch wichtig insgesamt fürs Controlling. [...] 
Und das wird dann schon auf diesem Level auch erfasst. Und die Kollegen, 
die Entwickler, die haben dann auch bestimmte Projektschlüssel und sagen: 
okay, ich habe jetzt einen Tag auf dem Projekt gearbeitet und den nächsten 
Tag auf einem anderen Projekt. Sonst können wir ja auch gar nicht nachhal- 
ten, wie viel Arbeitszeit ist eigentlich in welches Projekt geflossen. Es gibt 
ja auch viele Kollegen, die auf mehreren Projekten gleichzeitig arbeiten.“ 


(ND1) 


Eine über die Anrechnung der Arbeitsaufwände auf die Projekte hinausgehende 
Arbeitszeiterfassung gibt es bei NovoProd jedoch nicht. Es gibt zwar ein System, 
das registriert, wer wann die Büros betritt und verlässt, dieses wird jedoch nicht in 
Bezug auf die Arbeitszeit der Beschäftigten ausgewertet, wie ein Manager betont: 


„Deshalb haben wir auch keine Arbeitszeiterfassung, weder dort noch hier. 
Sie gehen hier zwar durch die Drehtür, die Drehtür erfasst auch wer rein 
gekommen ist, aber mehr aus Sicherheitsgründen, dass wenn jetzt hier 
irgendwie ein Flugzeug drauf stürzt, weiß man, wer ist tot. [...] Es ist mehr 
der Aspekt, es wird nicht ausgewertet, also: wie lang war der eigentlich 
in dem Gebäude, oder wann ist der dann da rüber gegangen. Die Drehtür 
ist mehr ein Sicherheitsaspekt als eine Arbeitszeitkontrolle. [...] Das ist 
übrigens ungewöhnlich in Indien, dass wir die Arbeitszeit nicht erfassen. 
Weil wir auch in Indien die Erfahrung gemacht haben, dass die Kollegen 
das auch schätzen, dass es keine strikte Kontrolle gibt.“ (ND1) 
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Die Einschätzung des Standortleiters, dass die fehlende Arbeitszeitkontrolle von 
den Beschäftigten schr geschätzt würde, wird durch Äußerungen der Entwickler 
bestätigt. Solange man seine Arbeitsaufgaben erledige, sei es möglich, die Arbeits- 
zeiten gemäß individueller Interessen zu gestalten. Vertraglich sind bei NovoProd 
40 Std. Arbeitszeit pro Woche vereinbart, und mit diesem Vertrag sind auch alle 
evtl. anfallenden Überstunden abgegolten. Angst, dass die Beschäftigten zu wenig 
arbeiten, muss NovoProd trotz des fehlenden Erfassungssystems nicht haben, 
wie der bereits zitierte Standortleiter ausführt: 


„Der Gruppendruck ist sowieso viel besser. Wenn das Team eine Aufgabe 
zu schaffen hat, dass geht Ihnen ja sicherlich nicht anders, wenn Sie da 
irgendwo forschen und da ist jetzt noch was fertig zu kriegen, wenn dann 
3 Leute da sitzen, geht der vierte nicht in den Baggersee. [...] Und das 
funktioniert viel, viel besser. Wir zahlen vernünftig, dann sind eben solche 
Sachen abgegolten.“ (ND1) 


Zu dieser Einschätzung passt, dass gerade bei nahenden Deadlines die Arbeitszei- 
ten aller Entwickler nach eigenen Angaben deutlich über die vertraglich vereinbar- 
ten 40 Std. hinausgehen. Die flexible Regelung der Arbeitszeiten bei NovoProd 
mache es jedoch möglich, dass die dabei anfallenden Überstunden von den Be- 
schäftigten in ruhigeren Phasen auch wieder „abgebummelt“ werden können, 
indem sie früher die Firma verlassen. Jedenfalls wird die Möglichkeit der persönli- 
chen Gestaltung der Arbeitszeiten von vielen Beschäftigten als ein sehr positiver 
Aspekt der Beschäftigung bei NovoProd hervorgehoben (vgl. Mayer-Ahuja 2011, 
auch Kapitel 6.3.4). 


Bei den beiden bisher behandelten Aspekten der Kontrollstruktur, der Anleitung 
und Anweisung, genauso wie bei der Überwachung der Arbeitsabläufe, zeigt sich 
also, dass NovoProd versucht, den Beschäftigten möglichst viel Verantwortung 
und Einflussmöglichkeiten auf ihre Arbeitsverausgabung zuzugestehen. So sollen 
diese ihre Arbeitsaufgaben möglichst selbstorganisiert bearbeiten und auch ihre 
Arbeitszeiten können sie selber in Länge und Lage beeinflussen, natürlich immer 
vorausgesetzt, sie sind in der Lage, ihre Arbeitsaufgaben in der vorgegebenen Zeit 
zu erledigen. Dementsprechend lässt sich für die Aktivitäten des Managements 
im Bereich der Kontrollstruktur bisher ein wenig detailliertes und formalisiertes 
Vorgehen konstatieren. 
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Messung und Bewertung von Arbeitsleistung 


Dies gilt auch für den letzten Aspekt der Kontrollstruktur, die Beurteilung und 
Belohnung der Arbeitsleistung der Entwickler. Grundsätzlich wird bei NovoProd 
die Leistung der Entwickler einmal pro Jahr in einem direkten Gespräch mit 
dem für einen Funktionsbereich der Applikation zuständigen Personalmanager 
erhoben und bewertet. Grundlage dieses Beurteilungsprozesses sind (wie bei 
ServiceTec) Zielvereinbarungen, die jeder Entwickler individuell am Anfang des 
einjährigen Turnus mit dem Personalmanager aushandelt. Nach 6 Monaten findet 
ein sogen. „Review-Treffen“ statt, auf dem die am Anfang des Jahres vereinbarten 
Ziele noch einmal diskutiert werden und bei etwaigen Veränderungen auch 
angepasst werden können. Die Bewertung der Arbeitsleistung erfolgt jedoch erst 
am Ende des zwölfmonatigen Zyklus. 


Die für die Entwickler festgelegten Ziele beinhalten bestimmte Erwartungen 
hinsichtlich der im nächsten Bewertungszeitraum zu erledigenden Arbeitsaufga- 
ben, aber auch einen persönlichen Entwicklungsplan, der eher „weiche“ Ziele 
hinsichtlich der persönlichen und qualifikatorischen Entwicklung der Entwickler 
formuliert. 

Die Ziele hinsichtlich der zu erledigenden Arbeitsaufgaben werden bei No- 
voProd top-down generiert. Aus den vom Steuerungsgremium für die nächsten 
Waves geplanten Zielen werden vom jeweiligen Personalmanager zunächst Team- 
ziele für jeden Funktionsbereich und daran anschließend individuelle Ziele für 
die einzelnen Mitglieder des Teams abgeleitet, wie ein Manager ausführt: 


„Da gibt’s schon konkrete Richtlinien, da gibt’s auch einen konkreten 
Prozess, wie das Ganze aussieht, wie das Ganze durchgeführt wird. Am 
Anfang des Jahres in der Regel Zielvereinbarungsgespräche: die Ziele wer- 
den definiert, eben top-down runtergebrochen. Ich bin dann letzten Endes 
derjenige, der dann aus den Bereichszielen die Teamziele ableitet. Aus den 
Teamzielen dann letzten Endes die individuellen Ziele ableitet.“ (NI1) 


Durch die Abhängigkeit von den zentral vom Steuerungsgremium für das nächste 
Jahr beschlossenen Entwicklungsplänen hängen diese arbeitsinhaltlichen Ziele 
stark von der jeweiligen Phase der Entwicklung ab. So berichten die Entwickler, 
dass zu Beginn der Produkt-Entwicklung, als primär Design- und Architektur- 
aufgaben die Arbeitsaufgaben bestimmten, diese arbeitsinhaltlichen Ziele von 
Lern- und Forschungszielen dominiert wurden, die wesentlich qualitativer Natur 
waren: 
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„I think 2005 was a very short time for them - like, only six months in that 
time they were in the organization. So at that time, it was a very high level 
goal. I didn’t have to give any detail. Because it was more, like, a trainıng 
and learning and doing certain tasks.“ (NI24) 


Ziele konnten zu dieser Zeit durchaus beinhalten, eine „innovative idea“ in 
einer bestimmten Hinsicht zu entwickeln (NIS) oder sich bestimmte technische 
Grundlagen zu erarbeiten (NI25). 

In späteren Phasen, in denen die technische Realisierung der Applikation im 
Zentrum stand, waren die Ziele entsprechend enger mit der technischen Umset- 
zung verknüpft. So wird in dieser Phase z.B. eine Erwartung an die produzierten 
Screens der Entwickler als Ziel formuliert, die sich auf die benötigte Zeit und 
Qualität bezieht, wie ein Gesprächspartner berichtet: 


„As I told you: in the development it’s more of delivering and other things. 
[...] For example: we have to finish all the development tasks on time and 
quality. [...] This is a kind of example of a goal. [...] So it’s basically that 
qualitative stuff. Also, we clearly define the ... ‘what is the achievement?’ 
thing, ‘how it will be measured’. (NI25) 


Diese Anforderungen unterscheiden sich nicht zwischen den beteiligten Ent- 
wicklern, sondern es handelt sich dabei um vom Steuerungsgremium bestimmte 
Qualitätsanforderungen fiir die nächste Wave, denen alle Entwickler in der be- 
treffenden Phase genügen müssen. Daher unterscheiden sich auch die arbeitsin- 
haltlichen Ziele der Entwickler nicht wesentlich voneinander: 


„If everybody is a developer, then the kind of goals they need to achieve is 
common for everyone, more or less.“ (NI25) 


Neben diesen arbeitsinhaltlichen Zielen gibt es für jeden Entwickler jedoch 
auch noch einen Bereich, der die Weiterentwicklung der persönlichen Qualifika- 
tionen und Kompetenzen betrifft. Hier werden z.B. Trainingsmaßnahmen zu 
bestimmten betriebswirtschaftlichen oder technischen Themen verabredet, die 
im nächsten Jahr besucht werden sollen. Darunter fallen aber auch bestimmte 
„soft skills“. So berichten manche Entwickler, dass sie als Vorbereitung auf eine 
Beförderung bereits einzelne Tätigkeiten eines fachlichen Leiters übernehmen 
sollen, wie z.B. dem Steuerungsgremium bestimmte Berichte vorzutragen, be- 
stimmte Sitzungen bei Teamtreffen zu leiten, o.ä. Ziele in diesem Bereich sind 
nach Lage des erhobenen Materials sehr unterschiedlich und anscheinend auch 
sehr stark von der jeweiligen Persönlichkeit und der individuellen Qualifikation 
abhängig. 
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Betrachtet man den Prozess der Zielvereinbarung, so fällt auf, dass bei NovoProd 
sehr viel Wert darauf gelegt wird, dass die Beschäftigten selber eine aktive Rolle 
bei der Definition der Zielvorgaben für das nächste Jahr spielen sollen, wie es 
sich auch in der Aussage eines Personalmanagers ausdrückt: 


„Ich bin dann letzten Endes derjenige, der dann aus den Bereichszielen 
die Teamziele ableitet. Aus den Teamzielen dann letzten Endes die indi- 
viduellen Ziele ableitet. [...] Und ich möchte natürlich auch von jedem 
einzelnen dann, wenn wir uns zum Zielvereinbarungsgespräch treffen, dass 
er sich Gedanken macht, was Ziele für ihn sein könnten, wenn er sich die 
Teamziele anschaut, inwieweit er sich da einbringen kann und wiederfinden 
kann. Wie er praktisch contributen kann, um die Ziele zu erreichen.“ (NI1) 


Zu diesem Zweck werden die vom Steuerungsgremium für den Gesamtbereich 
definierten und die für das Team vom Personalmanager daraus abgeleiteten Ziele 
vor den individuellen Zielvereinbarungsgesprächen im Team kommuniziert. Die 
Entwickler sind dann aufgerufen, sich zunächst selber zu überlegen, welche Ziele 
sie in der nächsten Phase erreichen wollen und welche Teile der Teamaufgabe 
sie übernehmen möchten. Auf diese Weise soll den Entwicklern die Möglich- 
keit gegeben werden, sich zu spezialisieren und Aufgaben zu wählen, die sie 
persönlich interessieren. In dem Zielvereinbarungsgespräch macht der jeweilige 
Personalmanager dann einen Vorschlag, wie er gedenkt, die individuellen Ziele 
zu definieren. Anschließend wird darüber diskutiert: 


„And then we sit together ... you know, give the objectives already ahead 
of time to the developer - so that he can look at it. And then also ... add, 
modify, change - whatever he wants to do it. Delete is not an option 
[lacht]. Add or modify - and then we sit in the meeting to discuss about 
the subjectives - with the measurements and the criteria, how it is going to 
be measured. [...] He also knows the overall company goals, and then his 
personal plan and the objectives. If it doesn’t match or he wants to make 
some modifications, then ... eh, we can discuss it in the meeting. And then 
he submits it. Then I approve that.“ (NI24) 


Nach Aussagen eines Personalmanagers könne in diesen Gesprächen häufig eine 
zufriedenstellende Lösung gefunden werden, wenngleich die vorliegenden Team- 
aufgaben auch eine klare Grenze der Beeinflussung bilden, weil sie erfüllt werden 
müssen: 


„Und dann gibt’s einfach schon Möglichkeiten, wenn man zusammensitzt 
und sagt: ‚Was hast du dir jetzt für Gedanken gemacht?‘ In ganz, ganz 
vielen Fällen gibt’s fast eine komplette Übereinstimmung, zu 90 % oder 
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sogar fast zu 100 %. In manchen Fällen, da gibt’s dann gewisse Abweichun- 
gen, [...] und dann hängt es einfach schlicht und ergreifend davon ab, [...] 
was sind denn jetzt letzten Endes die Ziele, was muss denn jetzt letzten 
Endes erreicht oder gemacht werden? Was wollen wir denn zusammen 
erreichen als Ziel? Und da muss eben der eine oder andere halt auch mal 
eine Aufgabe unter Umständen übernehmen und sich da einarbeiten, was 
in der Regel aber auch kein Problem ist. [...] Also es ist nicht so, dass es 
so läuft, dass ich die Ziele alle definiere, und dann ist es Prinzip nur noch 
ein Zuhören mehr oder weniger. Sondern [...] es ist schon erstmal, dass ich 
zuhöre. Ich höre mir an, was hat der Kollege sich für Gedanken gemacht? 
Wo sieht er sich in der Verwirklichung der Ziele, in der Erreichung der 
Ziele? Und dann wird eben drüber gesprochen. Und wenn es eine Über- 
einstimmung gibt, wunderbar - ist das Gespräch entsprechend kurz. Wenn 
es keine Übereinstimmung gibt, gut, dann wird eben diskutiert, was es 
sonst für Möglichkeiten gibt, Alternativen. In der Regel - zumindest bis 
zum heutigen Tage - haben wir es eigentlich immer geschafft, auf einen 
gemeinsamen Nenner zu kommen, und die Ziele dann festzulegen. So dass 
alle glücklich waren - oder zumindest zufrieden.“ (NI1) 


„Gemessen“ wird die Erreichung der Zielvorgaben schließlich am Ende des Jahres 
auch bei NovoProd in 5 Graden der Erwartungserfüllung für jedes definierte 
Ziel: „meets expectation, exceeds expectations, consistently exceeds, partially 
meets or does not meet“ (NI 24). Dabei werden die Ziele, die sich auf die per- 
sönliche Entwicklung beziehen, nicht in die Bewertung der Arbeitsleistung mit 
einbezogen: 


„Development plan is not really taken into the rating. Because those are 
the training needs and [...] it’s not, how the person performs.“ (NI25) 


Dementsprechend werden evtl. nicht eingehaltene Absprachen hinsichtlich der 
Weiterentwicklung von Qualifikationen nicht in die Leistungsbeurteilung einbe- 
zogen, sondern eher für die Planung der nächsten Phase berücksichtigt. 

Das „Rating“, also die Bewertung der Zielerreichung bezieht sich demnach bei 
NovoProd in erster Linie auf den Grad der Erreichung der arbeitsinhaltlichen 
Ziele. Zur Bewertung der Zielerreichung sitzen Projekt-, Personalmanager und 
der jeweilige Entwickler zusammen und diskutieren. Wie auch bei ServiceTec 
tragen die Entwickler zunächst eine Eigenbewertung in das Treffen, die dort 
mit der Bewertung durch den Projekt- und den Personalmanager konfrontiert 
wird. Zur Messung der Zielerreichung wird bei NovoProd nicht in dem Maße 
auf statistische und quantitative Messgrößen rekurriert, wie es bei ServiceTec der 
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Fall war - solche Systeme sind bei NovoProd gar nicht implementiert. Vielmehr 
sind die arbeitsinhaltlichen Ziele mit relativ groben Vorgaben hinterlegt, denen 
die programmierten Programmteile entsprechen müssen, wie ein Entwickler an 
einem Beispiel erläutert: 


„For example, let’s say that this person is working in my team, okay. He 
needs to do a specific objective of ... let’s say: a screen called task control. 
Okay? He needs to make sure that this task control is completed for the 
base called the ‘Release Candidate 1’ and all this ... volume readiness - with, 
eh, you know, the ... At the end of that - via any specific way. But he should 
not have, eh, the Prio one, Prio two and Prio three errors. And, eh, it 
should work in all these scenarios - A, B, C, D. And this is the time line - 
this is the measurement, how I have got to do.“ (NI24) 


Die Leistung dieses Entwicklers wird also daran „gemessen“, dass ein bestimmter 
von ihm verantworteter Teil der Applikation zu einem bestimmten Zeitpunkt, 
bei Fertigstellung einer ersten Version der Applikation (Release Candidate 1) vor- 
liegen und bestimmte Fehler (nach Kategorien eingeteilt) nicht mehr aufweisen 
soll. Ferner werden bestimmte Anwendungsbeispiele definiert (die „scenarios“), 
denen der Programmcode zu dem Zeitpunkt genügen soll. 

Der Abgleich mit den damit formulierten Erwartungen hinsichtlich Zeit und 
Qualität führt dann zur Einschätzung der Zielerreichung durch das Management. 
Dazu wird zunächst jedes definierte Ziel in den 5 Graden der Zielerreichung 
eingeschätzt und anschließend ein Durchschnittswert gebildet, der dann die 
Gesamtbewertung des jeweiligen Entwicklers darstellt. 


Dabei muss bei NovoProd jedoch berücksichtigt werden, dass das Funktionieren 
eines Teils der Applikation häufig daran gebunden ist, dass auch der Rest der 
Applikation lauffähig ist. Dementsprechend sind die Ziele der Entwickler auch 
nicht klar voneinander zu trennen, d.h. die Erfüllung der individuellen Ziele 
beruht zum großen Teil auch auf der Erfüllung der Teamziele: 


„I measure at the individual level. But we also have the team thing - so we 
know there is not a big gap. Yeah. What the team achieved, we also look at 
it, and then also look at where the individual has performed really, and how 
he has contributed. Because there shouldn’t be a mismatch - somebody has 
done very good and team has not delivered the whole thing. Then it doesn’t 
really match. So we [...] keep the whole picture in mind. Because there 
could be many things, which are beyond the person’s control, developer’s 
control.“ (NI25) 
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Der individuelle Anteil an der Erfüllung oder Nicht-Erfüllung der Teamziele ist 
daher auch von den Personalmanagern nicht immer trennscharf einzuschätzen. 
So ist die individuelle Nicht-Erreichung von bestimmten Zielen häufig auch 
von externen Faktoren abhängig. Grundsätzlich kann daher für den Prozess 
der Beurteilung und Bewertung der Arbeitsleistung bei NovoProd konstatiert 
werden, dass eine Kultur von „individual contributors“ (wie bei ServiceTec) 
bei NovoProd nicht anzutreffen ist. Die persönlichen Ziele werden demnach 
wesentlich stärker als Teil eines gemeinsamen Zieles der Teams kommuniziert 
und (wie die folgende Aussage eines Entwicklers zeigt) auch von den Betroffenen 
als solche begriffen: 


„Aber gleichzeitig habe ich die meisten Sachen eh immer als gemeinsa- 
mes Ziel verstanden. [...] Ich habe das weniger als Aufgabe, wie einen 
Vertrag, den man erfüllen muss, gesehen, sondern eher als gemeinsames 
Ziel-Ausmachen: Wo will man hin? Das versucht man halt, bestmöglich 
zu erreichen. Dies ist möglichst offen in der Art und Weise, was jetzt eben 
geklappt hat und was nicht geklappt hat. Und bisher hatte ich auch immer 
das Glück, dass ich mit meinen Vorgesetzten eben nie Probleme hatte, 
in der Beurteilung, woran es jetzt lag, wenn diese Sachen nicht erreicht 
worden sind, oder dass es eben teilweise wirklich externe Faktoren sind, die 
man nicht beeinflussen kann. Umgekehrt eben auch die Sachen, die eben 
geklappt haben, entsprechend gewürdigt wurden.“ (ND7) 


Es liegt wahrscheinlich an dieser engen Kopplung von Individual- und Teamzielen, 
dass sich in den untersuchten Teams auch selten große Schwankungen hinsichtlich 
der Zielerreichung finden, wie ein Personalmanager für sein Team beispielhaft 


beschreibt: 


„We... Normally, I think, the spread is mostly of people, who really meet 
the expectations, or people who exceed the expectations.“ (NI25) 


Entgegen der Praxis ServiceTecs versucht NovoProd auch nicht, die Leistungsdif- 
ferenzen innerhalb der Teams stark zu betonen. Das zeigt sich zum einen darin, 
dass jeder Entwickler im Anschluss an das jahrliche Treffen mit dem Projekt- 
und Personalmanager zwar sein persönliches Rating erhält, dieses Rating jedoch 
vertraulich zwischen Management und Entwickler behandelt wird und auch kein 
Ranking über das gesamte Team angestellt wird, wie es bei ServiceTec der Fall 
war. Zum anderen operiert NovoProd auch nicht mit statistischen Vorgaben hin- 
sichtlich der Eingruppierung von Entwicklern in die fünft Leistungsklassen, wie 
es bei Service Tec - und nach Mukherjee (2008) auch generell bei den indischen 
Servicefirmen - der Fall ist, wie ein Personalmanager erläutert: 
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„No, there is a trend what HR talks about is, you know ... In a team - 
if you have to raise the par ... for everybody, then you would naturally 
have some people who are exceeding expectations, some people meeting 
expectations, some people don’t meet the expectations or ... partly meeting 
expectations. There is something like that. And they look at: Okay - in a 
team of a certain size, I think, they would expect that some of them are like 
this, some of them are this. They expect, most of them will be meetings 
expectations - maybe about 60% or so are meeting. On that level. And 20% 
who exceeds - and then 10% consistently exceeds. And then 5% and 2% - 
something like that. They have some numbers. This is the general pattern, 
but we don’t go exactly with that.“ (N24) 


Bei NovoProd steht hingegen der Teamgedanke wesentlich starker im Vorder- 
grund. Dafür spricht auch, dass die jährlichen Ratings primär dem Zweck dienen, 
den Entwicklern eine Rückmeldung zu geben, wie die individuelle Leistung vom 
Management beurteilt wird, wie der folgende Personalmanager klarstellt: 


„First, we also look at the people, who have performed really well. That’s 
first thing - overall. And there is a percentage derived out of it, which 
determines the bonus, paid out to people. That’s just a by-product. The main 
focus is to give a holistic feedback of all the performance and then the rate, 
eh... Where they really stand, actually.“ (NI25 - Hervorhebung des Autors) 


Gehaltsrelevant sind diese Ratings eher nicht, wie sich bereits in der Formulie- 
rung des Personalmanagers ausdriickt, der die daran gekniipften Bonuszahlungen 
lediglich als „by-product“ der individuellen Zielerreichung bezeichnet. Für je- 
den Beschäftigten bei NovoProd gibt es je nach individueller Qualifikation und 
Erfahrungsstufe ein fixes Grundgehalt. An dieses Grundgehalt sind jährliche, leis- 
tungsbezogene Bonuszahlungen geknüpft, die in ihrer Höhe je nach Funktion im 
Unternehmen variieren. Für die Entwickler beträgt der variable, leistungsbezoge- 
ne Anteil am Grundgehalt nach Aussage der HR-Beauftragten für Application 
ca. 9% des Jahresgehalts (ND 3). In der Praxis bedeutet das für die Entwickler, 
dass der jährliche Bonus bei 100% Zielerreichung etwas mehr als ein dreizehntes 
Monatsgehalt umfasst: 


„100 percent bonus do almost a little more than your monthly salary, on 
an average.“ (NI21) 


Wenn ein Entwickler mehr als 100% Zielerfüllung erreicht hat, bekommt er 
demgemäß auch einen größeren Bonus: 


„So, there is an amount, which is promised in the beginning of the year, 
and if we meet 100 percent of the goals assigned to us, we get this amount. 
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If we meet less, it’s that percentage, if we meet more, it’s that much more. 
So if in our team the calculation went like, if I reach 112 percent of what I 
have set up to achieve, then I get 124 percent of the bonus, whatever was 
added above 100, doubles. So I get 124 percent of the amount promised.“ 


(NI21) 


Selbst wenn von NovoProd dabei ein überproportionaler Zusammenhang zwi- 
schen Zielerreichung und Bonuszahlung hergestellt wird (12% über 100% Ziel- 
erreichung ergeben 24% mehr Bonus), bleiben die Unterschiede zwischen den 
Leistungsgruppen damit in Bezug auf das Gesamtgehalt übersichtlich. So wer- 
den Entwickler, die ihre Ziele überfüllen, in der Regel mit ca. 105-120% Bonus 
veranschlagt (NI 25). Demnach bekommen besonders „gute“ Beschäftigte nur 
20% mehr Bonuszahlung als der Durchschnitt. Legt man ein durchschnittliches 
Monatsgehalt von knapp 45.000 Rupien brutto zugrunde!* und geht man ferner 
davon aus, dass der Bonus grob diesem Monatsgehalt entspricht, so erhielten 
Entwickler, die ihre Ziele übererreichen, gerade einmal 9.000 Rupien (knapp 140 
Euro) mehr im Jahr als die Kollegen, die „nur“ 100% Zielerreichung aufweisen 
können. 

Dies entspricht durchaus dem strategischen Vorgehen NovoProds, die Gehalts- 
schwankungen innerhalb der Teams möglichst zu begrenzen: 


„We tend to keep the differences minimal. Still there will be differences. 
But I say, totally it’s very minimum.“ (NI25) 


Auch hierbei steht wieder der Teamgedanke im Vordergrund. Interne Konkur- 
renz zwischen den Entwicklern um die Höhe der Gehälter soll eher vermieden 
werden: 


„Lam not giving the exact details of it, but the most important conside- 
ration, that we give, is the internal parity. So, [...] we try to ensure, that 
it should not be a case, where you take one person and other ten people 
are disappointed because of that. So, that is number one consideration. In 
NovoProd [...] it is sort of more or less balanced.“ (NI15 - Hervorhebung 
des Autors) 


Die Gehälter werden noch im Abschnitt über die Arbeitsmarktbeziehungen 
NovoProds Thema sein. An dieser Stelle ist festzuhalten, dass die Bewertung der 
individuellen Leistung sich bei NovoProd nicht in stark streuende Gehälter über- 
setzt. Der damit verkniipfte Versuch, einen Teamgedanken zu institutionalisieren 


14 Dieser Wert ergibt sich als grober Durchschnittswert aus den Angaben der Entwickler. 
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und dementsprechend Leistungsmessung nicht übermäßig zu individualisieren, 
verweist bereits auf die Form der Kooperationsbeziehungen bei NovoProd. 


6.3.3 Kooperationsbeziehungen 
Kooperationsbeziehungen innerhalb von Application 


Der Blick auf die Kontrollstruktur ergab, dass den Beschäftigten bei NovoProd 
durch ein wenig formalisiertes und detailliertes System der Anleitung und An- 
weisung große Handlungsspielräume für die Planung und Durchführung ihrer 
Arbeitsaufgaben zugestanden werden und dass das System der Leistungsbewer- 
tung vergleichsweise wenig individualisiert ist. Versuche, den Erfolg eines Teams 
individuell herunterzubrechen und die Leistung jedes einzelnen Entwicklers 
möglichst exakt zu messen, sind bei NovoProd wenig entwickelt. Als Grund für 
dieses Vorgehen konnte vor allem die Art der bei NovoProd zu bearbeitenden 
Aufgaben identifiziert werden, die es auf der einen Seite aufgrund ihres komple- 
xen Charakters erschweren, a priori enge und detaillierte Vorgaben hinsichtlich 
des Vorgehens der Arbeitsverrichtung zu definieren und die es auf der anderen 
Seite aufgrund der Interdependenzen der einzelnen Komponenten der Applikati- 
on auch erschweren, die Gründe für Fehlschläge oder Erfolge einzelnen Personen 
eindeutig zuzuschreiben. Zudem wurde gezeigt, dass es strategisch auch gar nicht 
beabsichtigt ist, die Leistungsdifferenzen innerhalb der Teams stark zu betonen 
oder gar zu nutzen, um interne Konkurrenzverhältnisse zwischen den Entwick- 
lern zu inszenieren oder zu verschärfen. Vielmehr wird bei NovoProd darauf 
geachtet, das interne Gleichgewicht („internal parity“) innerhalb der Teams zu 
wahren. 

Der Hintergrund dafür scheint nach Lage der Interviews die Befürchtung zu 
sein, dass interne Konkurrenzverhältnisse die Kooperation und Kommunikati- 
on der Entwickler untereinander erschweren könnten. Wie in Abschnitt 6.2 (S. 
174) ausgeführt, versucht NovoProd, sich gezielt von einer Art des Offshoring 
abzugrenzen, das die Kommunikation der beteiligten Akteure stark kanalisiert 
und den Kontakt in den jeweiligen Projektmanagern bündelt. Vielmehr findet 
die interne Kommunikation innerhalb des Entwicklungsnetzwerkes bei Novo- 
Prod auf allen Ebenen der beteiligten Teams statt. Berücksichtigt man zudem die 
Ausführungen zum komplexen und interdependenten Charakter der verteilten 
Entwicklung, so ergeben sich für die Entwickler bei Application extrem hohe 
Kommunikations- und Kooperationserfordernisse, sowohl innerhalb des Teams, 
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als auch (innerhalb des gesamten Entwicklungsnetzwerkes) zu den anderen betei- 
ligten Einheiten Vision und Platform. 

Zwar wurde ausgeführt, dass die in Application verteilten Arbeitsaufgaben im 
wesentlichen in einer bestimmten Zahl von Screens bestehen, die individuell zuge- 
wiesen werden. Daraus aber abzuleiten, dass die von den Entwicklern geleistete 
Arbeit im wesentlichen in Einzelarbeit bestünde, wäre verfehlt. Zwar arbeiten 
alle Entwickler in erster Linie an ihren „eigenen“ Screens, jedoch ist diese Bearbei- 
tung in einen breiten Zusammenhang von Teamaktivitäten eingebettet. Denn 
auch wenn jeder Screen in der Verantwortung eines Entwicklers liegt, beteiligen 
sich die anderen Teammitglieder an der Bearbeitung. Auf den wöchentlichen 
Teammeetings, die auch der Statuserhebung dienen (vgl. Kapitel 6.3.2), berichten 
in der Regel alle Entwickler des Teams vom Fortschritt der Bearbeitung ihrer 
Screens und können in diesem Zusammenhang auch offene Fragen und Probleme 
bei der Entwicklung ansprechen, die anschließend innerhalb des Teams diskutiert 
werden. Dieser Austausch der Entwickler dient nicht nur dem nahe liegenden 
Zweck, sich gegenseitig bei Problemen zu helfen - dies findet ohnehin alltäglich 
auf informeller Ebene statt - sondern zudem dem Zweck, dass alle Teile des 
Teams auch über die anderen Screens und damit zusammenhängende Probleme 
informiert werden und so auch ein besseres Bild des „großen Zusammenhangs“ 
gewinnen sollen. Ein Qualitätsbeauftragter erläutert anhand eines Teams, dass 
aus mehreren kleineren Teamteilen besteht: 


„We have weekly synchronization meetings. [...] So, we all get in touch in 
such regular synchronization meetings. We share our issues, our learning 
amongst others. Such a forum also help us in probably learning from what 
issues the other team has got or what sort of an solution they have invented 
- which we can probably directly use in our teams and so on. So, such 
forums also are useful and they work pretty well.“ (NI5) 


Wie sich aus der zitierten Aussage entnehmen lässt, betreffen viele Probleme, die 
bei einem Screen auftreten, ebenso andere Screens oder auch andere Funktionsbe- 
reiche, z.B. wenn es um grundsätzliche Funktionen der Technologieplattform 
und deren Einbindung in die Benutzeroberfläche geht. Daher beteiligen sich 
in den Teamdiskussionen grundsätzlich alle Entwickler eines Teams, um bei 
Problemen eine Lösung zu finden, wie ein Entwickler ausführt: 


„And each time actually, new components are coming from technology 
teams. So [...] we should have the flexibility to decide also, because these 
new components are coming in, we may use the new components, because 
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the old components had some other issues as well and some limitations. So, 
we decide it from our side.“ (NI9) 


Doch es sind nicht nur äußere Einflüsse, die innerhalb des Teams diskutiert 
werden. Wie in Abschnitt 6.3.1 erwähnt, bearbeitet Application nicht nur die 
Benutzeroberfläche der Applikation, sondern auch eine Zwischenebene, die 
zwischen Plattform und Benutzeroberfläche geschaltet wird und bestimmte, von 
der Plattform nicht generisch bereitgestellte Funktionen und Informationen 
liefert. Diese Komponenten können von allen Teams innerhalb von Application 
genutzt und auch gemeinsam in Bezug auf die nötigen Funktionen diskutiert und 
verändert werden, wie der bereits zitierte Entwickler weiter ausführt: 


„We have some components, [...] which we have developed for our internal 
uses, which are common to us, and then, if there is some new enhancement 
or some change in that, all of us decide on that: ‘ok, we’ll include something 
in this or something in that’. [...] We discuss that smaller change also, so, 
it’s a very informal.“ (NI9) 


Es zeigt sich also, dass in Application zwar individuelle Arbeitspakete an die 
Entwickler vergeben werden, diese jedoch so stark zusammenhängen, dass für die 
Entwickler damit die Notwendigkeit besteht, sich stetig in ihrem je individuellen 
Vorgehen mit den anderen Mitgliedern des Teams abzustimmen und z.T. auch 
auf ein gemeinsames Vorgehen zu einigen. 


Zudem ist das ganze Team gefragt, wenn zu Beginn einer Wave die Anforde- 
rungen an die Applikation von Vision kommuniziert werden. Zwar findet die 
Diskussion über die Ziele der jeweiligen Wave innerhalb des Steuerungsgremi- 
ums statt, von dem die indischen Beschäftigten weitgehend ausgeschlossen sind. 
Trotzdem werden die indischen Teams im Anschluss an die Diskussion um eine 
Einschätzung gebeten, ob die geplanten Ziele auch realistisch sind. Dazu sitzen 
zu Beginn jeder Wave die indischen Teams zusammen, um die geplanten Ziele 
des Steuerungsgremiums zu diskutieren und zu entscheiden, ob sie die geplanten 
Aufgaben in der vorgegebenen Zeit auch umsetzen können. 

So zerfällt die Arbeitszeit der Entwickler bei NovoProd auch recht gleichmäßig 
in Einzel- und Teamarbeit, wobei das Verhältnis stetig variiert und sich auch je 
nach Projektphase unterschiedlich darstellt. So bestehen zu Beginn einer Wave, 
wenn zentrale Entscheidungen bzgl. des weiteren Vorgehens getroffen werden 
müssen, höhere Kommunikations- und Kooperationsnotwendigkeiten als am 
Ende der Wave, wenn es für die Entwickler nur noch darum geht, die anliegenden 
Arbeitsaufgaben rechtzeitig fertig zu stellen. 
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Kooperationsbeziehungen zu den anderen Teams des 
Entwicklungsnetzwerkes 


Die Kooperations- und Kommunikationsanforderungen an die Entwickler hören 
jedoch nicht an den Teamgrenzen auf. Die Entwicklung der Screens begründet 
auch starke Abhängigkeiten von den beiden anderen an der Entwicklung der 
Gesamtapplikation beteiligten Einheiten Plattform und Vision. Gemäß der Ziel- 
struktur NovoProds findet der daraus resultierende Kontakt auf allen Ebenen 
der an der Entwicklung beteiligten Teams statt. So sind zum einen die Projekt- 
manager aller drei Einheiten, die für eine bestimmte Funktionalität zuständig 
sind, in ständigem Kontakt. Doch auch unterhalb der Projektmanagerebene ist 
zwischen den Entwicklern ein reger Austausch nötig. Für die indischen Entwick- 
ler bedeutet dies, dass sie sich z.B. an andere Beschäftigte bei Vision wenden, 
um Unklarheiten bzgl. der Anforderungen zu klären oder sich Details bzgl. der 
grafischen Vorgaben geben zu lassen. Zu Platform bestehen noch wesentlich 
engere Kontakte, da dieses Team die wesentlichen Funktionalitäten bereitstellt 
und so zentraler Ansprechpartner bei Unklarheiten oder Informationsbedarf 
bzgl. der Basisfunktionalitäten ist. Nach Aussagen der Entwickler finden solche 
Klärungsgespräche zwischen verschiedenen Einheiten teilweise mehrmals täglich 
statt. Diese hohe Intensität der Kommunikation ist nach Angaben des folgenden 
Projektmanagers auch der Grund, warum die Kommunikation bei NovoProd 
nicht durch die jeweiligen Projektmanager kanalisiert wird: 


„Sehen sie, wir sind ein Projektteam im Rahmen einer großen Projektteam- 
struktur. Wir arbeiten nicht allein. Wir arbeiten in einem großen Verbund. 
[...] Also unser Projekt besteht aus sechs, aus neun Leuten. Und unsere 
Counterparts in Platform sind zwischen 30 und 40. Dann gibt es Vision. 
Da sind nochmal fünf oder sechs Leute. [...] Und die müssen sich alle 
untereinander unterhalten. Das kann, es geht praktisch nicht, dass die Kom- 
munikation nur über die jeweiligen Projektleiter geht. [...] Sonst werde ich 
ganz schnell zum Flaschenhals, und ich kann die Menge an Kommunikation 
nicht bewältigen, die dann stattfindet. Darum haben wir verhältnismäßig 
früh angefangen, die ,peer contacts‘ aufzubauen, also die indischen Kolle- 
gen mit direkten Namen von ihren ‚counterparts‘zu versorgen, damit sie 
kommunizieren. In der Literatur lernt man, dass das Kommunikations- 
modell über die Manager läuft. Das ignorieren wir einfach. Die, ja, so ist 
es bei NovoProd in Indien klassisch nicht. Und wir versuchen, die Leute 
möglichst direkt auch miteinander sprechen zu lassen.“ (ND4) 


Um diese Kooperation auch über die unterschiedlichen Standorte hinweg zu ge- 
währleisten und die Kommunikation zu vereinfachen, hat NovoProd zu Beginn 
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der Entwicklung viel Wert darauf gelegt, dass sich die beteiligten Entwickler aller 
Einheiten persönlich kennenlernen. Daher waren erhöhte Reiseaktivitäten in 
allen Einheiten zu verzeichnen. Die Beschäftigten besuchten sich gegenseitig, 
meist zu dem Zweck, dass die erfahrenen deutschen Kollegen erste Schulungen 
und Trainings für die neuen indischen Entwickler durchführten. Diese Trainings 
fanden sowohl in Deutschland als auch in Indien statt. Nach Aussagen der beteilig- 
ten Akteure waren diese persönlichen Treffen von entscheidender Bedeutung, um 
die stete Kommunikation zwischen den Einheiten zu gewährleisten (vgl. NI1). 

Denn gerade zu Beginn der Entwicklung bestanden durchaus Spannungen 
zwischen den deutschen und den indischen Beschäftigten, was auf der einen Seite 
an dem für die meisten Beteiligten gänzlich neuen globalen Setup lag, auf der 
anderen Seite aber auch auf Befürchtungen der deutschen Beschäftigten beruhte, 
dass ihre Jobs langfristig genau von jenen übernommen würden, die sie anleiten 
sollten. Gerade in der Zeit, als das neue Produkt ins Entwicklungsstadium kam, 
baute NovoProd den indischen Standort aggressiv aus, und es war nicht klar, 
ob diese Expansion in Indien nicht auf Kosten „deutscher“ Arbeitsplätze gehen 
würde. 


„Ich habe das in meinem allerersten Bereich, wo ich hier angefangen habe, 
erlebt. Da kam dann irgendwann mal der Chef rein und sagte: ‚Unsere 
Gruppe wird abgebaut und wird in Indien neu aufgebaut‘. Und dann hat er 
aber gesagt: ‚Ja, das ist aber ein längerer Zeitraum. Wir machen so weiter 
wie bisher‘. Und dann hieß es, also längerer Zeitraum hieß ein bis zwei 
Jahre. So lange hat sich es letztendlich hingezogen. Und dann war es aber 
zu dem Zeitpunkt so, dass auch gerade interne Wechsel relativ schwierig 
waren. Das heißt, es gab keine klare Perspektive, was soll danach passieren. 
Das heißt, es hieß schon: ‚Klar, wir schmeißen keinen raus. Wir finden 
irgendwas für euch‘. [...] Aber da war die Stimmung dann schon erst mal 
im Keller. [...] Da geht natürlich die Perspektive weg. Und das war eine 
Zeit lang auch schlecht gehandled, weil halt die Manager entschieden haben: 
‚Wir verlegen das nach Indien‘. Aber sie haben nicht gesagt, was sie konkret 
mit den deutschen Mitarbeitern danach machen wollen.“ (ND2) 


Um diese Spannungen, die die effektive Kommunikation zwischen den Einheiten 
erschwerten, aufzulösen, war der direkte Kontakt nach Aussage des folgenden 
Gesprächspartner sehr wichtig. Er diente dazu, „das Eis zu brechen“: 


„Um dann noch mal auf den Punkt zurückzukommen: Was für mich frap- 
pierend oder ziemlich auffällig war, war eigentlich die ersten Monate, als 
wir mit dem indischen Team so angefangen haben, so zarte Verbindungen 
zu knüpfen, die ersten Meetings, wo man dann auch vorgestellt hat, was 
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sind die Ziele, was ist die Vision, was soll eigentlich gemacht werden - das 
war schon komisch irgendwie vom Gefühl her. Also irgendwie hat man 
einfach gemerkt, dass - ja wie soll ich es beschreiben -, dass da einfach so eine 
unsichtbare Maurer dazwischen ist. Deswegen habe ich auch vorhin gesagt, 
es war wichtig, dass die Kollegen hergekommen sind, um wirklich das Eis 
zu brechen, dass man sich mal sieht, dass man miteinander spricht, dass 
man auch nicht in einem formalen Meeting miteinander kommuniziert. 
[...] Also dass man einfach dann wirklich auch sich dran gewöhnt auf allen 
Seiten, dass man grad in so nem Umfeld, wo man verteilt entwickelt, dass 
da Kommunikation wirklich das A und O ist.“ (NI1) 


Auch wenn im Laufe der Zeit klar wurde, dass der Aufbau des indischen Ent- 
wicklungszentrums (zumindest bis zum Zeitpunkt der Untersuchung) keine 
Entlassungen in Deutschland nach sich ziehen würde, und sich die Befürchtun- 
gen der deutschen Beschäftigten damit zunächst als gegenstandslos erwiesen 
hatten, bleibt nichtsdestotrotz die standortübergreifende Kommunikation und 
Kooperation ein Dauerthema innerhalb von NovoProd und wird von fast allen 
Beschäftigten von Application als wichtigstes Feld für zukünftige Verbesserungen 
in der globalen Struktur NovoProds genannt. 


„Also aus meiner Sicht ist der allerwichtigste Aspekt überhaupt, dass man 
sich massıv über Kommunikation Gedanken machen muss. Das ist das al- 
lerallerwichtigste. [...] Es gibt keine Faustregel. Es kommt definitiv auf die 
Projektphase an, wie viel man kommuniziert, wie oft man kommuniziert. 
[...] Also das ist wirklich, Kommunikation ist für mich das A&O. Wenn 
man das hinbekommen will, muss man reisen. Man muss vor Ort sein. Es 
geht nicht ohne. Man muss unstrukturierte Zeit mit den Leuten verbringen 
und verteilte Projekte.... Wir hatten durch diese - diese Sachen, die uner- 
lasslich sind, sind einfach sehr, sehr teuer. Man muss viel reisen, man muss 
da sein, man muss Zeit mit den Leuten verbringen, man muss die Leute 
herholen, damit sie die anderen kennenlernen. Wir hatten zum Gliick die 
Möglichkeiten dafür. Aber wer versucht, ein verteiltes IT-Projekt mit engen 
Schnittstellen aufzubauen, das verteilt ist, ohne dabei genügend Reisemittel 
zur Verfügung zu stellen, der kriegt ernsthafte Schwierigkeiten.“ (ND4) 


Zwar wurde zu Beginn der Entwicklung versucht, alle Entwickler zusammenzu- 
bringen und persönliche Kontakte zu etablieren, doch dieser persönliche Kon- 
takt zwischen den Beschäftigten konnte nicht über die Zeit in allen Bereichen 
aufrechterhalten werden. Viele Beschäftigte, die zu Beginn im indischen Entwick- 
lungszentrum beschäftigt waren, haben in der Zwischenzeit das Unternehmen 
bereits wieder verlassen oder das Team gewechselt, so dass innerhalb von Ap- 
plication stetiger Bedarf besteht, Gelegenheiten zu schaffen, an denen sich die 
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Beschäftigten persönlich kennenlernen können. Jedoch entsteht genau an diesem 
Punkt in den letzten Jahren ein Problem bei NovoProd, da das Reisebudget 
für die Entwicklung des neuen Produkts stark gekürzt wurde (ND 4) und die 
Frequenz, in der Beschäftigte an die anderen Standorte reisen können, damit 
deutlich abgenommen hat: 


„Wir drehen eigentlich kontinuierlich am Geldbudget für die Reisebudgets 
nach unten. [...] Es ist nicht mehr so wie 1996, dass ich beliebig oft mit 
Business Class geflogen bin, wie immer ich wollte. So war es letztendlich 
1996. Es ist einfach heute so, dass Sie ein Reisebudget haben und dass der 
Manager in dem Fall wirklich in der Regel abzeichnet, ob Sie den Flug 
machen oder nicht. Und der muss da gucken, dass er das Reisebudget 


einhält.“ (ND6) 


In der Folge führt dies dazu, dass zum Zeitpunkt der Untersuchung nicht mehr 
alle indischen Kollegen ihre deutschen „Counterparts“ persönlich kennengelernt 
haben. In der Regel bekommen nur Beschäftigte, die schon länger in den Projek- 
ten sind und auch eine zentrale Rolle in diesen spielen, weil sie aufgrund ihrer 
erhöhten Erfahrung auch verantwortungsvollere Arbeitsaufgaben zugewiesen 
bekommen haben, weiterhin die Genehmigung, an andere Standorte zu reisen, 
wie folgender Entwickler erklärt: 


„Usually only the key people are sent, because it is expensive to travel and, 
you know, stay there for some time and things like that, so it’s just about 
the key people, who go there, gain the knowledge, come back and share it 
with other people here. So, we are a team of 35, I would say, about 11 or 12 
of us only, maybe 14 have got this opportunity till now. [...] In NovoProd 
usually the perception is, that every developer also gets a chance to go to 
Germany at least once, at least once is the perception, but when that at 
least once comes it’s totally up to your manager or to the requirements of 
your team.“ (NI21) 


Diese Einschränkungen in den Reiseaktivitäten werden damit auch zu einem Pro- 
blem für die standortübergreifenden Kooperationsbeziehungen. Dieses Problem 
stellt sich besonders stark für die indischen Beschäftigten, da sie die oberste Ebene 
des Produkts entwickeln, daher sehr stark von den beiden anderen Abteilungen 
abhängig sind und erhöhten Informationsbedarf gegenüber deutschen Kollegen 


haben. 


„Also jetzt ist es inzwischen ein bisschen dramatischer, also dramatisch ist 
auch falsch, aber es ist halt reduziert worden. [...] Aber gerade in Indien ist 
es, denke ich mal, sehr wichtig, dass man sich auch persönlich kennt. Das 
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hilft halt enorm. Und das kann man halt nicht alles über Telefon, e-Mail, 
Messenger, was weiß ich, erreichen. Also es ist schon deutlich wichtiger, 
dass man auch mal mit den Leuten drüben war.“ (ND5) 


Das Hauptproblem für die indischen Beschäftigten ist nach Aussagen der Ge- 
sprächspartner, dass die für ein bestimmtes Problem zuständigen deutschen 
Kollegen nicht leicht zu identifizieren seien, und es daher häufig unklar sei, wer 
in einer bestimmten Situation anzusprechen ist und wer bei Problemen helfen 
kann. Zwar gibt es formale Verantwortlichkeiten und diese werden auch in Indien 
kommuniziert, doch nach Aussage des folgenden Gesprächspartners sind diese 
formalen Zuständigkeiten keineswegs ausreichend: 


„Ja, aber das reicht nicht. Also wenn man die offiziellen Verantwortlichkei- 
ten sieht, ist es bei weitem nicht detailliert genug, dass man herausfinden 
könnte, wer eine Frage beantworten könnte. Stellen Sie sich vor, Sie rufen 
bei VW an und Sie sagen: ‚Ich hab ein Problem mit der Aufhängung meiner 
Zündkerze‘. Ich glaube, das würde eine ganze Weile dauern bis man den 
Ingenieur finden würde, der dafür verantwortlich wäre. Das ist bei uns 


ähnlich.“ (ND4) 


Selbst wenn der betreffende Ansprechpartner schließlich identifiziert wurde, 
leide der nötige Informationsfluss stark, wenn die beiden Gesprächspartner sich 
nicht persönlich kennen, wie ein deutscher Brückenkopf unumwunden zugibt: 


„Weil dann wird es halt einfach schwieriger. Das beobachten wir immer 
wieder, die indischen Kollegen, die gute Arbeit leisten, haben es einfach 
schwieriger, wenn der deutsche Kollege sie nicht, nicht Angesicht zu An- 
gesicht sieht, weil es einfach weiter weg ist. Das ist halt nur irgendeine 
Stimme aus dem Telefon. [...] Der Kontakt bzw. die Bereitschaft von dem 
deutschen Kollegen, dem indischen Kollegen - also das ist jetzt nicht nur 
Indien, das ist überall, weltweit - in einem anderen Land zu helfen, ist 
natürlich eher gegeben, wenn er den auch mal gesehen hat, wenn er auch 
mal vielleicht persönlich mit ihm geredet hat. Diese weichen Faktoren, die 
man, wenn man in einem Besprechungszimmer gemeinsam sitzt, dass man 
vielleicht beim Rausgehen nochmal fragt: ‚Wie geht’s denn Deiner Frau? 
Was machen...‘- was weiß ich - ‚was macht der Hund?‘ Irgend sowas. Diese 
Sachen sind natürlich bei diesen Telefongesprächen wesentlich schwieriger, 
weil häufig sind es dann auch nicht Eins-zu-Eins-Gespräche [...] und dann 
geht dieser persönliche Aspekt ganz weg und es dauert dann einfach län- 
ger, den Respekt und im gewissen Sinne auch die Freundschaft oder das 
Wohlwollen des anderen zu erhalten.“ (ND2) 
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Diese durch die eingeschränkten Reisemittel in der letzten Zeit bei Application 
auftretenden Probleme der direkten Kommunikation und Kooperation stellen 
auch einen weiteren Grund für die bereits in Abschnitt 6.2 erwähnte Persistenz 
der Brückenköpfe innerhalb des globalen Entwicklungsnetzwerkes dar. Diese 
fungieren nicht nur - sofern nötig - mit ihrer Erfahrung als fachliche Anleiter 
der indischen Teams, sondern besitzen auch ihre persönlichen Netzwerke inner- 
halb des deutschen Standortes, die sie nutzen können, um die Kommunikation 
zwischen den deutschen und indischen Entwicklern zu unterstützen. So kön- 
nen sich die indischen Entwickler an die deutschen Brückenköpfe wenden, um 
zu erfahren, wen sie mit ihrem Problem am besten ansprechen, und wenn es 
Schwierigkeiten in der Zusammenarbeit gibt, kann der betreffende Brückenkopf 
versuchen, diese in einem persönliche Gespräch mit dem deutschen Kollegen zu 
thematisieren und evtl. zu lösen. 

So haben die deutschen Brückenköpfe in den standortübergreifenden Kommu- 
nikations- und Kooperationsbeziehungen eine ganz wichtige Funktion. Sind 
sie auch grundsätzlich bemüht, nicht zum „Flaschenhals“ zu werden, an dem 
intensive und möglichst multilaterale Kommunikation zwischen den beteiligten 
Akteuren scheitert, werden sie doch als Vermittler durch die Fluktuation in 
den indischen Teams und den dadurch verursachten Verlust der persönlichen 
Netzwerke permanent benötigt. So findet sich also auch im Bereich der Koopera- 
tionsstrukturen eine konfliktreiche Situation, in der die strategische Zielstruktur 
der Kooperationsbeziehungen bisher nicht vollständig realisiert werden konnte. 
Ein Grund dafür liegt wiederum in den Arbeitsmarktbeziehungen NovoProds. 


6.3.4 Arbeitsmarktbeziehungen 


Wie erwähnt, beruht das Verlagerungsmodell NovoProds stark auf den indi- 
viduellen Selbstorganisationsfähigkeiten und der Erfahrung der Beschäftigten 
an den Offshore-Standorten, was die Form der Aufgabenorganisation und der 
standortübergreifenden Kooperationsbeziehungen betrifft. Zudem handelt es 
sich bei der Entwicklung des neuen Softwareproduktes - auch wenn nur ein Teil 
der Applikation im indischen Entwicklungszentrum hergestellt wird - um eine 
sehr komplexe und damit auch anspruchsvolle Arbeit, die erhöhte Qualifikati- 
onsanforderungen an die Entwickler stellt. 

Der indische Standort kann demnach nur in das standortübergreifende Ent- 
wicklungsnetzwerk integriert werden, wenn ausreichend gut qualifizierte Beschäf- 
tigte am indischen Arbeitsmarkt rekrutiert und möglichst lange im Unternehmen 
gehalten werden können. Denn nur in stabilen Teamzusammensetzungen können 
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sich die Beschäftigten tief in ihre Arbeitsaufgaben und die damit zusammenhän- 
genden Problemstellungen einarbeiten und gleichzeitig auch die notwendigen 
persönlichen Netzwerke zu anderen Beschäftigten - auch an anderen Standorten - 
knüpfen. Der boomende indische IT-Standort mit seinen aus der stetig steigenden 
Nachfrage nach TT-Fachkräften folgenden Fluktuationsraten, stellt NovoProd 
deshalb vor große Herausforderungen. 


Rekrutierungsbemühungen 


Zum Zeitpunkt der Untersuchung schien NovoProd die Rekrutierung einer 
ausreichenden Zahl von gut ausgebildeten Beschäftigten noch gut zu gelingen, 
wie folgender Manager berichtet: 


„In Indien war das eben anders. Da konnten wir in bestimmten Bereichen 
in Indien sehr zügig wachsen. Es ist auch heute noch so. Wenn sie heute 
einen Bereich aufbauen wollen, 100 Leute. Da hatten wir grad in Indien 
wieder einen Bereich - oder meinen Bereich. Den haben wir jetzt gerade 
vor anderthalb Jahren aufgebaut. Wenn man jetzt 250 Leute aufbauen muss, 
dann kann man höchstens 50 vielleicht aus bestehenden Teams raus ziehen. 
Danach fangen alle anderen natürlich an zu schreien. Das ist ja auch klar, 
das nimmt die besten Leute weg. Das heißt 200 mussten wir auch neu 
einstellen und zwar in 3 Monaten.“ [F: Und in Indien geht das?] „Ja, in 


Indien geht das.“ (ND1) 


Das liegt sicherlich auch daran, dass das indische Entwicklungszentrum in den 
letzten Jahren eher moderat gewachsen ist und daher im Vergleich zu anderen in 
Indien aktiven [T-Unternehmen (vor allem der stark expandierenden indischen 
IT-Dienstleistungsunternehmen) nur wenige neue Beschäftigte eingestellt werden 
mussten. Zum Zeitpunkt der Untersuchung wurden die Wachstumspläne für das 
indische Entwicklungszentrum jedoch erweitert, so dass sich die HR-Abteilung 
wesentlich stärker um Rekrutierung kümmern muss: 


„Wir sind ja nicht so stark gewachsen. Ich mein, wenn man dann von 100 
auf 200 wächst, praktisch in nem ganzen Jahr 100 Leute braucht, also in 
nem Monat gerade mal 10, dann ist es relativ einfach das auch zu handlen 
[englische Aussprache - PF]. Die kriegt man auch aus dem Arbeitsmarkt 
ohne Probleme. Ich hab noch viel Zeit investiert in die Auswahl und so. 
Wir sind jetzt im vergangenen Jahr von 1500 auf 2500 Leute gewachsen. 
Wenn sie 1000 Leute wachsen wollen in nem Jahr, dann müssen sie natürlich 
auch ganz andere Prozesse haben, dann ist es nicht mehr ganz so einfach.“ 


(ND1) 
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Doch auch wenn der Bedarf an Arbeitskräften durch die ehrgeizigeren Wachs- 
tumsziele gestiegen ist, bietet der indische Arbeitsmarkt NovoProd in Bezug auf 
die Rekrutierung nach Angaben des zuständigen HR-Managers nach wie vor sehr 
gute Bedingungen. In den zweieinhalb Jahren, seit er die Rekrutierungsbemü- 
hungen NovoProds am indischen Standort leitet, hat er nach eigenen Angaben 
3300 Jobangebote an Bewerber ausgesprochen, für die 225.000 Bewerbungen 
eingegangen wären (vgl. NI16). Nach einer ersten Sichtung der Bewerbungen 
reduziert sich die Zahl der für geeignet erachteten Bewerber zwar, jedoch blieben 
nach Aussagen eines anderen Mitarbeiters der HR-Abteilung trotzdem noch für 
jede ausgeschriebene Stelle durchschnittlich knapp 100 Bewerber übrig, die in die 
engere Auswahl kämen und in einem Interview begutachtet würden (vgl. NI15). 
Aufgrund des (im Vergleich zu den indischen IT-Dienstleistern, die teilwei- 
se fünfstellige Zahlen von Beschäftigten pro Jahr eingestellt haben) geringeren 
Personalbedarfs finden bei NovoProd auch keine Massenrekrutierungen - z.B. 
in Form von Campus Hirings - statt, wie sie am Beispiel von ServiceTec aus- 
führlicher erläutert wurden (vgl. 5.3.4). Vielmehr wird bei NovoProd weiterhin 
sehr selektiv für bestimmte (neu einzurichtende - oder wieder zu besetzende) 
Positionen rekrutiert, wie ein Mitarbeiter der HR-Abteilung ausführt: 


„So most of the recruitments, because it is not mass recruitment and it is 
non-campus recruitment. [...] So, if we hire somebody, we are particularly 
in terms of the role, that we are able to offer that person. So, in most cases it 
works out like that. So, we have a manager sitting out for the same position, 
who sort of explains the role to the person and ensures, that that person’s 
competence is mapped that particular role, then only we take a decision, 
but having the case of mass recruiting or campus recruiting, then it would 
have been very difficult, because then we first recruit the people and then 
put them in the roles. Right now most of the recruitment happens against 
a particular role, so it’s not so difficult as such. Yeah, we look for people 
with a good experience, if we are looking for marketing the product or if 
we are looking for support or sales, or we are looking for development, 
[...] whatever we are looking for, we are pretty clear and we accordingly 
hire people, who face that particular job.“ (NI15) 


Die große Nachfrage nach den von NovoProd ausgeschriebenen Stellen ermög- 
licht es dem Unternehmen, in Bezug auf Einstellungsvoraussetzungen sehr an- 
spruchsvoll zu sein. Das zeigt sich zum einen darin, dass NovoProd grundsatzlich 
nur Bewerber akzeptiert, die von den „Top 100“ Lehrinstitutionen Indiens kom- 
men. 
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„There will be about 3.000 to 3.500 colleges in this country. [...] We look 
at the top 100. So we have narrowed down to a list of 100 colleges that we 
want to target.“ (NI16) 


Zudem werden bei NovoProd - wieder im Gegensatz zu den Initiativen der 
indischen IT-Dienstleister, IT-ferne Studienrichtungen als Rekrutierungsmasse 
zu erschließen - bisher ausschließlich Absolventen von IT-affinen Engineering- 
Studiengängen rekrutiert, die zwischen den in Indien aktiven IT-Unternehmen 
am stärksten umkämpft sind. 


„So, most of the people working here, be engineers. So, either they will be 
computer engineers or software engineers, or they will be engineers from 
different streams, who have adopted themselves as software professionals.“ 


(N15) 


Ein weiterer guter Indikator fiir die hohen Qualifikationsanspriiche ist auch die 
Tatsache, dass NovoProd keine Berufsanfänger einstellt. Nach Aussagen eines HR- 
Mitarbeiters sind 2 Jahre Berufserfahrung Pflicht, um von NovoProd akzeptiert 
zu werden. Dies sei auch der entscheidende Grund, warum NovoProd sich nicht 
an „Campus-Recruitments“ beteilige: 


„Because the type of work, that we do, going to campus was not a part of 
our strategy. [...] So typically we take people with more than two years of 
experience.“ (NI15) 


Die bei NovoProd interviewten Gesprächspartner haben daher fast alle die ersten 
Jahre ihrer Karriere in anderen IT-Unternehmen verbracht. Zum absoluten 
Großteil handelte es sich dabei um indische IT-Dienstleister, in denen sie direkt 
nach ihrem Uni-Abschluss angefangen und die sie dann nach ein paar Jahren 
wieder verlassen haben, um eine Beschäftigung bei NovoProd anzutreten. 


Trainingsmaßnahmen 


Ein Grund für die Rekrutierung von berufserfahreneren Beschäftigten ist, dass 
NovoProd sich von Anfang an auf technische Kenntnisse seiner Mitarbeiter 
verlassen möchte. Die ersten Jahre verbringen Beschäftigte bei indischen IT- 
Dienstleistern - wie am Beispiel von Service Tec gezeigt werden konnte - in erster 
Linie im Bereich der technischen Umsetzung, häufig mit wechselnden Gegen- 
ständen und unterschiedlichen Technologien. Daher haben die bei NovoProd 
eingestellten Beschäftigten eine breite technische Ausbildung und auch erste 
Programmiererfahrungen gesammelt, auf die NovoProd aufbauen kann. 
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Dementsprechend kurz kann NovoProd das initiale technische Training nach 
der Einstellung halten. Zwar gibt es bestimmte Technologien, die aufgrund des 
Produktcharakters speziell bei NovoProd eine große Bedeutung haben, und auch 
einige Methoden sind firmenspezifisch und müssen daher zu Beginn einer Be- 
schäftigung bei NovoProd von allen Beschäftigten neu gelernt werden. Diese 
Technologien und Methoden lassen sich jedoch mit technischem Grundwissen 
zügig lernen. Von den 2,5 bis 3 Monaten, die jeder Beschäftigte nach der Einstel- 
lung in einem initialen Einführungsprogramm verbringt, entfällt daher nur ein 
kleiner Teil auf die Vermittlung der technischen Grundlagen. Vielmehr bemüht 
sich NovoProd in dem Einführungskurs, den neuen Beschäftigten die spezifische 
Unternehmensstruktur und -kultur näher zu bringen - eine Schwerpunktset- 
zung, die gerade auch vor dem Hintergrund der an die indischen Beschäftigten 
gestellten Kommunikations- und Kooperationsanforderungen nachvollziehbar 
ist. 

Ein noch wichtigerer Indikator für die geringe Relevanz der technischen Schu- 
lungen nach der Einstellung ist allerdings die bei Application feststellbare Praxis, 
die initialen Trainings stark zu verkürzen. So berichten Gesprächspartner, dass 
in ihrem Falle das initiale Training von knapp drei Monaten auf drei bis vier 
Wochen reduziert wurde. 


„Generally, when somebody joins NovoProd, they undergo a training - 
by default. [...] But now, what we have done is - we have cut short that 
training. [...] They go through basic things like intercultural training, then 
... induction program for five days and plus - maybe overview of NovoProd, 
technology and what NovoProd do. [...] Three weeks. In some cases maybe 
four. Three to four weeks.“ (NI4) 


Statt in zentralen Einführungsprogrammen werden bei Application die neuen 
Beschäftigten eher „on-the-job“ im betreffenden Projektteam angelernt. Die- 
se Schulung findet dann meist parallel zur Arbeit in Form von kurzen sogen. 
„Knowledge-Transfer Sessions“ statt, die von anderen Kollegen durchgeführt wer- 
den. Unter „Knowledge-Transfer Sessions“ sind weitgehend informelle eins zu 
eins Treffen zwischen dem neuen und einem in einem speziellen Feld sehr er- 
fahrenen Kollegen zu verstehen, die meist in Form von kleinen Präsentationen 
abgehalten werden (vgl. NI 4). Inhalt ist weniger technisches Grundlagenwissen; 
vielmehr führen die erfahreneren Kollegen die neuen Teammitglieder in die für 
das Produkt spezifische Anwendung bestimmter Technologien, die Details der 
Produktarchitektur und das technische Design ein. 
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Der Grund für dieses Vorgehen liegt zum einen, wie erwähnt, darin, dass mit 
der Einstellung von berufserfahrenen Bewerbern bereits solide technische Grund- 
kenntnisse vorausgesetzt werden können, zum anderen aber auch in der Art 
des bei NovoProd benötigten Wissens. Zwar ist das Wissen um bestimmte Pro- 
grammiersprachen und technische Konzepte auch für die Arbeit bei NovoProd 
unerlässlich - schließlich wird letzten Endes ein Softwareprodukt entwickelt. 
Jedoch ist dies nach Aussagen der Gesprächspartner für die Arbeit innerhalb von 
Application nur ein kleiner Teil des erforderlichen Wissens. Wesentlich entschei- 
dender - und erfolgskritischer - sei das Wissen um die Geschichte, die spezifische 
technische Architektur und das Design des zu entwickelnden Produkts. Dieses 
Wissen sei aufgrund des innovativen Charakters des zu entwickelnden Produkts 
jedoch nicht in Form von zentralisierten Einführungskursen zu vermitteln, da 
entsprechende Dokumentationen nicht im voraus verfügbar seien, sondern eher 
parallel zur Entwicklung selbst erarbeitet werden, wie ein fachlicher Leiter aus- 


führt: 


„Because ours is a new product - so everything is built from scratch. So, 
when we started off, there was no training material as such. Because we are 
building something from scratch, there can’t be training material. So, what 
has happened is: over a period of time, we have learned by ourselves all the 


stuff.“ (NI28) 


Die Aussage des zitierten Gesprächspartners verweist auf den bereits ausführlich 
behandelten Charakter der Arbeit bei NovoProd. Es geht bei NovoProd nicht 
nur um die technische Umsetzung vorgegebener Spezifikationen, sondern die 
Arbeitsaufgaben der Entwickler enthalten auch ganz wesentlich Design- und 
Planungsaufgaben. Zudem handelt es sich um die Entwicklung eines neuen Pro- 
duktes, daher liegen gerade zu Beginn der Entwicklung noch keine Dokumente 
oder ähnliches vor, an denen sich Trainingsmaßßnahmen orientieren könnten. 
Dementsprechend ist bei NovoProd auch das persönliche Erfahrungswissen von 
größerer Bedeutung für die Beschäftigten als das Wissen um die technischen 
Grundlagen, wie der folgende Interviewpartner bestätigt: 


„Man merkt einfach, man kann ja viel in training, trainings, eh, investieren, 
und die Leute zu dem Training schicken und hierhin schicken und extra 
einen Trainer aus Deutschland und so weiter und so fort, aber das ersetzt 
niemals Erfahrung, das ersetzt niemals Erfahrung. Die Leute miissen Er- 
fahrung machen, eh, und das ist was, wo man merkt, da fehlt es noch. Das 
kommt jetzt mit der Zeit, und das hilft auch, dass wir hier eben sehr viele 
Teams vorfinden, wo die Leute schon Erfahrung haben, und wir uns dann 
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einfach mit denen zusammensetzen können, die reviewen unser coding, 
eh, geben Hilfestellung, Ratschläge und so weiter, das hilft enorm, aber 
Erfahrung ist was, was jetzt momentan noch fehlt, das stimmt, dass ein 
neues Team halt aufgebaut worden ist. Ich hatte ein paar erfahrene Leute 
bekommen, die intern gewechselt sind von anderen Teams, eh, macht sich 
schon bemerkbar, wenn jemand schon einfach ein paar Jahre im Unterneh- 
men ist, selbst wenn er mit der Technologie jetzt unmittelbar nichts zu tun 


hatte.“ (NI1) 


Dieses Erfahrungswissen könne demnach nicht zentral vermittelt, sondern müsse 
über „learning on-the-job“ angeeignet werden. Das ist nach Aussage der im 
Folgenden zitierten HR-Managerin auch der Grund, warum NovoProd eher 
auf arbeitsbegleitende Einführungen durch die unmittelbaren Kollegen als auf 
zentralisierte Schulungsmafßßnahmen zu Beginn der Beschäftigung setzt: 


„Aber auf der inhaltlichen Seite ist es schwer, die Leute weiter zu ent- 
wickeln, denn ich kann Leuten, die an einem Standardprodukt arbeiten, 
wenn die auch von der Uni kommen, die können die ganzen Module ler- 
nen, es gibt Kurse zur Programmierung. Auch da gibt's... Wir haben ein 
innovatives Produkt: Da gibt es gar nichts, was ich trainieren kann bei 
Innovationen, sondern ich bin eigentlich gezwungen, Dinge auszuprobie- 
ren. Ich kann mir dann bei „User Interface Design“ schon Hilfe holen von 
zentralen Organisationen. Da gibt es Kurse, die heißen ‚Design Innovati- 
on‘, wo Stabsabteilungen sagen, wie man eigentlich vorgehen sollte, um 
Screens zu designen. Aber letzten Endes ist das learning by doing.“ (ND3 - 
Hervorhebung des Verfassers) 


Zwar kann bei NovoProd so die Zeit des initialen Trainings reduziert werden, 
weil zum einen technische Kenntnisse durch Einstellung berufserfahrener Perso- 
nen vorausgesetzt werden können und zum anderen die wichtigen Trainings eher 
parallel zum Arbeitsablauf „on-the-job“ erfolgen, doch dies bedeutet keinesfalls, 
dass die Beschäftigten schnell in die Projekte zu integrieren seien. Bis sie zum 
eigenständigen Arbeiten innerhalb des Teams befähigt sind, dauert es - wieder im 
Vergleich zu Service Tec - eine eher lange Zeit. So berichten Projektmanager, dass 
Beschäftigte, die neu in das Projektteam kommen, zwischen 3 und 6 Monate brau- 
chen, bis sie die nötige Selbständigkeit erreicht hätten, um ihre Arbeitsaufgaben 
weitgehend eigenverantwortlich zu erledigen (vgl. u.a. NI5, NI24). 

Dieser lange Zeitraum erklärt sich einerseits aus der Komplexität des Produktes 
und des damit zusammenhängenden technischen Designs, andererseits aber auch 
daraus, dass für ein eigenständiges Arbeiten bei NovoProd nicht nur individuelle 
Kenntnisse und Erfahrungen wichtig sind, sondern auch die Etablierung von 
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sozialen Netzwerken - gerade zu Beschäftigten an anderen Standorten - die 
Arbeitsproduktivität und die Fähigkeit, die eigenen Arbeitspakete erfolgreich zu 
bearbeiten, maßgeblich beeinflusst (vgl. 6.3.3). Die Etablierung dieser (persönli- 
chen) Kontakte braucht Zeit, auch dies trägt zu der langen Einarbeitungszeit bei, 
gerade wenn (wie gegenwärtig bei NovoProd zu beobachten) der direkte persön- 
liche Kontakt zu den Kollegen an anderen Standorten durch die Reduzierung des 
Reisebudgets erschwert wird. 


Umgang mit Personalfluktuation 


Grundsätzlich kann daher konstatiert werden, dass (aufgrund des für die Arbeit 
bei NovoProd nötigen spezifischen Wissens und der sozialen Netzwerke) einzel- 
ne Beschäftigte nur unter großem Zeit- und Ressourceneinsatz ersetzbar sind. 
Verlässt ein Entwickler ein Projektteam, so bedeutet dies ein großes Problem, 
wie ein Qualitätsbeauftragte verdeutlicht: 


„We are a bit more resource intense, you know. Because along with the 
person, he carries with him a lot of skill sets - skill sets of course, we can 
train the other person, yes. But he ... would carry a lot of information 
about the project and also his relationships, right? Because he would have 
already built a lot of rapport with the German counterparts, eh. If this is 
the issue, whom to contact? And that is something, which he must have 
learned after several librations. So that’s the real key, which is very difficult. 
So we get a new person, probably we can train him. But then, to really 
work within the team and really get to understand the team dynamics, 
understand, whom to approach what, and what to do in this sort of a 
situation, that’s - that’s the thing, which will probably take time. [...] Even 
if we bring a new person on board, he will be technically well-equipped, 
fine! But for each and every small issue, the manager has to really step in. 
Because you'll say: ‘Oooh, with this issue, Pll probably contact this person 
and get the work done from him’. That’s where the manager will be pushed 
in to the greatest extent, so he wouldn’t get enough time for himself - but 
that’s the real issue.“ (NI5) 


Aus dieser Abhangigkeit NovoProds von den individuellen Wissens- und Erfah- 
rungsbeständen seiner Beschäftigten und deren damit einhergehender schwieri- 
ger Ersetzbarkeit, erklart sich auch, dass die Vermeidung von Fluktuation bei 
NovoProd größte Priorität genießt. Es konnte bereits in den vorhergehenden 
Abschnitten gezeigt werden, dass die strategische Zielstruktur NovoProds bis- 
her nur in jenen Teams weitgehend umgesetzt werden konnte, in denen die 
Zusammensetzung über die Zeit stabil geblieben ist. In den Teams hingegen, die 
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mit verstärkter Personalfluktuation zu kämpfen hatten, muss auf wesentlich re- 
striktivere Elemente der Arbeitskontrolle zurückgegriffen werden, als eigentlich 
beabsichtigt ist. So müssen Arbeitsaufgaben vom jeweiligen Vorgesetzten aufwän- 
diger spezifiziert und definiert und ihre Bearbeitung engmaschiger überwacht 
und angewiesen werden. Zudem müssen die deutschen Brückenköpfe in diesen 
Teams stärker Vermittlungsaufgaben übernehmen, weil sich die persönlichen 
Kontakte zu deutschen Counterparts nur langsam entwickeln. 

Betrachtet man die von der Firma bereitgestellten Angaben zu den aktuellen 
Fluktuationsraten, so fällt auf, dass NovoProd im Vergleich zu ServiceTec noch 
immer eher moderat von Fluktuation betroffen zu sein scheint. Der interviewte 
HR-Mitarbeiter gibt für das gesamte indische Entwicklungszentrum eine durch- 
schnittliche aktuelle Fluktuationsrate von knapp 9 % an. In der in dieser Studie 
untersuchten Abteilung Application ist diese Rate noch geringer und wird von 
ihm mit ca. 7,5% veranschlagt (NI15). 


Der Befund, dass NovoProd als Hersteller von Standardprodukten mit weniger 
Fluktuation konfrontiert ist, überrascht vor dem Hintergrund anderer Studien 
zunächst nicht. So argumentieren z.B. Upadhya und Vasavi (2006), dass einer 
der wichtigsten Gründe, warum Beschäftigte „ihre“ Firma verlassen, die Suche 
nach anspruchsvolleren Tätigkeiten ist. Lacity, Rudramuniyaiah und Iyer (2008) 
schreiben sogar, dass die Suche nach anspruchsvoller Arbeit der wichtigste Grund 
für Personalfluktuation in Indien ist. Die multinationalen Standardsoftware- 
Hersteller stehen dabei in dem Ruf, in ihren indischen Entwicklungszentren im 
Vergleich zu den meist indischen IT-Dienstleistungsunternehmen die anspruchs- 
vollste und befriedigendste Arbeit anzubieten und zudem meist großes Renomé 
für ihre weltweit bekannten Marken zu besitzen (vgl. Upadhya und Vasavi 2006, 
S. 50ff.), weshalb Beschäftigte seltener diese Unternehmen verlassen würden. 
Diese Befunde werden durch das bei NovoProd erhobene Material bestätigt. 
Nach den Gründen gefragt, warum sie von ihrer vorherigen Firma zu NovoProd 
gewechselt sind, geben viele Interviewpartner an, gezielt nach einem Produkther- 
steller gesucht zu haben (z.B. NI3, NI6, NI14, NI24, NI28). Als Grund für diese 
Präferenz wird meist einer oder mehrere der vier folgenden Aspekte angeführt: 
Erstens geht die Tatsache, dass NovoProd Produkte herstellt und keine Services 
für externe Kunden anbietet, für die Beschäftigten mit der Erwartung (und in der 
Mehrzahl der Fälle auch mit der realen Erfahrung) einher, dass die Arbeitszeiten 
in Produktfirmen moderater sind, weil man sich nicht über Zeitzonen hinweg an 
die Arbeitszeiten von Kunden anpassen müsse. In einer Produktfirma würden 
eigene Planungen gemacht, und man müsse sich nicht den Forderungen der 
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Kunden beugen, die meist einen starken Zeit- und Arbeitsdruck aufbauen würden, 
wie der folgende Entwickler, der von Service Tec zu NovoProd gewechselt ist, 
berichtet: 


„Main difference, I would say, is - it’s like, NovoProd being a product 
company, its pressure is relatively less than we had at ServiceTec. And, 
it actually results in a better work balance at NovoProd as compared to 
ServiceTec. [...] It’s like, I have a little more time for myself and friends 
than I had in ServiceTec. [...] Actually, yeah - the work pressure, which 
makes you work late or ... Because in a product company you have your 
own deadlines. In a service company you have deadlines, set by the client.“ 


(NI23) 


Tatsächlich wird NovoProd von vielen der interviewten Gesprächspartner eine 
gute und eher gleichmäßige Verteilung der Arbeitszeiten attestiert, wie beispiel- 
haft der folgende Entwickler ausführt: 


„I think, [...] in service industries it gets too hectic at one point in time, 
that is, when you are trying to deliver a product or an application. And 
then the remaining point of time, it’s like, you are sitting idle, this is - I 
think, that balanced work is somehow missing in service based companies.“ 


(NI3) 


Zweitens wird von den Gesprachspartnern in Bezug auf eine Beschaftigung 
bei einer Produktfirma positiv hervorgehoben, dass hier an einer „globalen 
Lösung“ gearbeitet wird, die anschließend von vielen Leuten oder Unternehmen 
genutzt wird. Dies steht in deutlichem Kontrast zu dem den Servicefirmen 
zugeschriebenen eher partikularen Fokus, der sich nur auf einzelne Kunden 
richte: 


„And also, I think, the approach, that the product based companies follow, 
Ithink, is somewhat different than a service based companies, because, I 
mean, in a product based, you want to make a product that is applicable 
to everyone. But in service based you are told only for that person - and 
there is a difference. [...] When you want to do something, you want to do 
something that helps everyone to find a global solution. And then want to 
give the same kind of solution to different people in different ways. And 
this is more appealing to me.“ (NI3) 


Der dritte Grund, eine Anstellung bei NovoProd anzustreben, ist der Marken- 
name von NovoProd. IT-Dienstleister arbeiten meist im Hintergrund großer 
Kundenunternehmen und erledigen unterstützende Aufträge für diese. Zwar gibt 
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es auch renommierte Dienstleistungsunternehmen, jedoch sind diese eher für 
ihre Beratungsleistung bekannt, wie z.B. IBM oder Accenture. Produktfirmen 
hingegen, gerade jene großen multinationalen Standardsoftwarehersteller wie 
NovoProd, sind meist berühmt für einzelne Produkte und werden mit diesen 
auch assoziiert. Man denke z.B. an die allgegenwärtige Bürosoftware von Micro- 
soft. Teil eines solchen Unternehmens zu sein, wird von den Beschäftigten schon 
als Vorteil empfunden, der sich angeblich auch sehr gut im eigenen Lebenslauf 
ausnehme, wie der beispielhaft im Folgenden zitierte Projektmanager erklärt: 


„NovoProd was a better company at that [time]. Since also they have a 
brand value. And my former company was still a small company. Even 
though it went public, it was still a small company. And then I got an 
offer from NovoProd, which, Ithought, probably makes much more bra 
... it also adds brand value to the overall ... your bio-data - it looks good 
[lachend]. And also [...] Ithought, NovoProd product development would 
also add much more value, it gives much more exposure to me.“ (NI7) 


Der wichtigste - vierte - Grund für eine Beschäftigung bei NovoProd scheint 
nach Lage der Interviews jedoch - und damit werden die Ergebnisse von Upadhya 
und Vasavi (2006) und Lacity, Rudramuniyaiah und Iyer (2008) bestätigt - die 
Qualität der angebotenen Arbeit zu sein. Die Beschäftigten erwarten, in der Pro- 
duktentwicklung mit den neuesten Technologien und Methodologien arbeiten 
zu können, wohingegen Angestellt von Dienstleistungsunternehmen häufig mit 
älteren Technologien umgehen müssen, weil die Kunden alte Systeme wie z.B. 
Mainframes oder Cobol-Programme benutzen. 


„Why do they join? They join, because people would like to work in a 
product company. There are multiple reasons. First of all, the kind of work 
that you do in a service company - if you are working in a mainframe, 
Cobol - it’s not interesting! I mean, this doesn’t help much after two years, 
three years in your career. So they look for a shift.“ (NI6) 


Darüber hinaus wird der langfristige Ansatz von Produktfirmen geschätzt, der es 
ermögliche, sich vertieft mit bestimmten Problemlösungen zu beschäftigen und 
spezialisiertes Wissen aufzubauen. Als Entwickler von betriebswirtschaftlicher 
Standardsoftware bietet NovoProd Beschäftigten zudem die Möglichkeit, über 
den rein technischen Bereich hinaus wertvolle fachliche Kenntnisse zu gewinnen, 
die als besonders wichtig für ihre weitere Karriere gelten, wie folgender Manager 
erläutert: 


„Was ich auch in den Interviews mit den Kollegen, die ich hier eingestellt 
habe, oftmals festgestellt hab, dass die einfach nach einer gewissen Zeit auch 
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an einem Produkt einfach arbeiten wollen. Dass sie nicht einfach irgendwie 
was implementieren wollen, oder irgendwie jetzt auf Kundenanforderungen 
hin eine Spezialentwicklung machen wollen, sondern dass sie wirklich auch 
mal für einen langen Zeitraum einfach am Produkt mitarbeiten wollen. 
Und auch wirklich neueste Technologien kennen lernen wollen, auch 
Zeit haben wollen, sich da einzuarbeiten, auch Wissen haben wollen, was 
Geschäftsprozesse anbelangt.“ (NI1) 


So ist NovoProd also aufgrund des eigenen Verlagerungsmodells, der Art der 
angebotenen Arbeit und ihres Firmennamens ein sehr attraktiver Arbeitgeber. 
Dies erklärt die starke Nachfrage nach den von NovoProd ausgeschriebenen 
Stellen, und es sind diese Eigenschaften, die NovoProd in dem Bemühen betont, 
die Beschäftigen langfristig im Unternehmen und damit die Fluktuationsraten 
niedrig zu halten. 


War es für ServiceTec charakteristisch, der Fluktuation vor allem mit positi- 
ven Anreizen in den Bereichen Karriere, Gehalt, Postings oder Arbeitsumfeld 
zu begegnen, versucht NovoProd gezielt über den arbeitsinhaltlichen und - 
organisatorischen Bereich, Beschäftigte von einem Jobwechsel abzuhalten. Ein 
für Application verantwortlicher Vertreter des höheren Managements bringt im 
Folgenden die bereits ausführlich geschilderte Form der standortübergreifenden, 
internationalen Kooperationsstrukturen bei NovoProd explizit in einen engen 
Zusammenhang mit den Bemühungen, die Fluktuationsraten zu senken: 


„Wir machen’s eher tief integriert [...] und wir fahren eigentlich eine Inte- 
gration auf Entwickler-Level, also die Entwickler kennen sich untereinan- 
der. [...] Also das ist eine ganz andere Art und Weise der Zusammenarbeit. 
Ich würde mal sagen, dass ein großer Teil unserer Projekte so gemanaged 
wird und nur ein geringer Teil so ist, dass da nur 2 Leute miteinander 
kommunizieren. Das geht natürlich, bei so einem Ding [,,Standardansatz 
des Offshoring“ - PF, vgl. auch Abschnitt 6.2, S. 175] brauch ich das nicht. 
Die kommen nie raus, die sitzen da und machen nur Spezifikationen. Aber 
die Frage ist natürlich: Ist das langfristig ein Modell, das funktioniert, weil 
die Job-Zufriedenheit ist schon auch gering. Alle wollen gern die Position 
haben, und wenn man dann hier nicht durchstößt, dann gehen die Leute. 
Und zwar sehr schnell. Das jetzt nur als Grundzusammenhang zu dem 


Thema.“ (ND1) 


Der vom Gesprächspartner erläuterte „Grundzusammenhang“ zwischen Fluktua- 
tion und Arbeitsorganisation enthält bereits den Kern der strategischen Bemühun- 
gen NovoProds zur Vermeidung von Fluktuation. Anstatt die Arbeitsprozesse ge- 
gen Fluktuation zu immunisieren und sie damit von den einzelnen Beschäftigten 
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so unabhängig wie möglich zu machen, steht bei NovoProd eher die Erhöhung 
der Job-Zufriedenheit der Entwickler im Vordergrund, die bei der strategischen 
Planung der Aufgabenorganisation im indischen Entwicklungszentrum mitreflek- 
tiert wird. Dieses Vorgehen scheint erfolgreich zu sein: Dass NovoProd bei der 
Organisation der Arbeitsprozesse großen Wert auf Selbstorganisationsfahigkeiten 
legt und Angestellten fiir die Bearbeitung ihrer Arbeitsaufgaben soviel freie Hand 
gibt wie möglich, wird von den Beschäftigten sehr positiv aufgenommen, wie 
beispielhaft folgender Personalmanager bemerkt: 


„Because, as I told you: the thing was the kind of independence and the 
kind of responsibility that was given to people in NovoProd. [...] And 
that’s the one reason which made me ... stay in NovoProd for such a long 
time. So I still don’t think this kind of culture exists outside.“ (NI25) 


Ein Entwickler bestatigt diese Annahme: 


„Ihe first thing was, that every individual is given a lot of responsibility 
for what they do. That’s one thing, that I always looked for, because I 
feel, if somebody is holding me by the finger and telling me, to do this, 
do that, do this, do that, according to his own requirements, I feel my 
ability of creativity and innovation is contained. So, that is something, 
that’s an environment again, that I prefer not working under, eh, so which 
is, why I feel, NovoProd is far better than any other organization, that I 
have heard of at least, because an individual is given total responsibility for 
his work piece and he does, what he feels with it and he is answerable also 
for anything, that goes wrong with it, which is fair enough.“ (NI21) 


So finden sich unter den bei NovoP rod interviewten Gesprächspartnern viele, die 
durchaus eine langfristige Perspektive im Unternehmen sehen und dies explizit 
auf die Zufriedenheit mit ihren Arbeitspaketen zurückführen: 


„I have seen that, at least in NovoProd, people tend to fall in love with the 
work, because of the lot of challenges in the work. Not directly related 
only to technology, but also functional and understanding the needs of the 
customer.“ (NI25) 


Ein anderer Gesprächspartner, antwortet auf die Frage, ob er sich in 5 Jahren 
immer noch bei NovoProd sehe: 


„100%. [...] No, seriously! I mean, it’s like, I am appreciating my work 
currently, I am enjoying it. I have this job satisfaction. That is enough for 
me.“ (NI14) 
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NovoProd setzt also strategisch auf eher arbeitsinhaltliche und -organisatorische 
Anreize, um die Beschäftigten im Unternehmen zu halten und scheint angesichts 
der vergleichsweise niedrigen Fluktuationsraten mit diesem Ansatz in Indien 
bisher auch erfolgreich zu sein. Dies bedeutet jedoch nicht, dass der indische 
Arbeitsmarkt für NovoProd damit keine Herausforderung mehr sei oder sich die 
Fluktuation ausschließlich über arbeitsinhaltliche Anreize kontrollieren liesse. 


Die Fluktuation bleibt schon deshalb ein Dauerthema, weil 9% (bzw. 7,5% bei 
Application) Fluktuation für NovoProd aufgrund der starken Abhängigkeit der 
Arbeitsprozesse von den individuellen Wissens- und Erfahrungsbeständen der 
Beschäftigten immer noch eine „bösartig hohe Zahl“ (ND6) ist. Der Einfluss der 
Fluktuation auf die strategische Zielstruktur NovoProds, vor allem im Bereich 
der Aufgabenorganisation und Kooperationsbeziehungen, wurde bereits erwähnt. 
Auch die Tatsache, dass einige Teams mit sehr viel höheren Fluktuationsraten zu 
kämpfen haben, verstärkt die Gefahr, die von diesen - für indische Verhältnisse 
moderaten - Fluktuationsraten für NovoProd ausgeht. Zudem muss auch für 
NovoProd berücksichtigt werden, dass sich die Fluktuation schwerpunktmäßig 
auf die Gruppe der Beschäftigten konzentriert, die bis zu 3 Jahre im Unterneh- 
men sind, so dass für die Stufe der Entwickler erwartet werden kann, dass die 
Raten noch einmal deutlich über den 9, bzw. 7,5% liegen (ND6). 

Desweiteren kommt zum Tragen, dass die Suche nach anspruchsvoller Arbeit 
zwar ein wichtiger - möglicherweise der wichtigste - Grund ist, aus dem indische 
IT-Beschäftigte häufig die Unternehmen wechseln, aber keinesfalls der einzige. 
Wie in Kapitel 3 argumentiert wurde, befähigt der indische Arbeitsmarkt die 
Beschäftigten, anspruchsvolle Arbeit und günstige Beschäftigungsverhältnisse (in 
Form von schnellen Karrieren und hohen Gehältern) zu fordern. Und gerade 
diese beiden Bereiche sind bei NovoProd durchaus problematisch. 

In seiner deutschen Firmenzentrale setzt NovoProd traditionell auf flache Hier- 
archien, Beförderungen sind dementsprechend selten. Viele deutsche Beschäftigte 
bei NovoProd dauerhaft Entwickler und sehen darin auch kein Problem, weil 
ihre Erfahrung im Unternehmen und in ihrem Fachbereich sich zwar nicht in 
neuen Titeln, wohl aber in der Art der ihnen anvertrauten Arbeiten widerspie- 
gelt, was für sie wesentlich wichtiger ist als die genaue Jobbezeichnung, wie ein 
Manager ausführt: 


„Wir haben in Deutschland trotzdem den Entwickler, und Entwickler wird 
eigentlich ziemlich lange getragen. Weil letzten Endes, sagen wir mal, ein 
Entwickler, der jetzt erfahrener ist, der kriegt automatisch einfach mehr ver- 
antwortliche Tätigkeiten, die dann in Richtung Architektur gehen, die dann 
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in Richtung Projektmanagement gehen. Der hat eigentlich automatisch, 
mehr oder weniger nach einer gewissen Zeit - vorausgesetzt die Fähigkeiten 
sind eben da - hat der automatisch diese Verantwortlichkeiten. [...] Es ist 
eben nur, es hängt nur nicht an einer bestimmten Position eben.“ (NI1) 


Dabei setzt NovoProd in Deutschland darauf, dass die Beschäftigten in erster 
Linie arbeitsinhaltlich motiviert sind und daher nichts anderes sein wollen als 
Entwickler, also gerade nicht anstreben, Manager mit Personalverantwortung zu 
werden: 


„Ich habe viele Kollegen, die sind seit 14 Jahren Entwickler. [...] So und da 
gibt’s ein paar Development Architekten, die sehen diese Auszeichnung, 
dass sie Development Architect sind, als: ich möchte nie Manager sein. Für 
die kommt Manager ganz weit hinter Architekt, sag ich jetzt mal ganz 
einfach, weil die haben nämlich keine Ahnung - die Manager. Das ist die 
Übersetzung von Manager bei den Kollegen. Und da haben sie auch nicht 
ganz unrecht, fachlich gesehen.“ (NI6) 


NovoProd versucht nun, diesen Umgang mit Beförderungen auch im indischen 
Entwicklungszentrum zu praktizieren, weil befürchtet wird, dass grundsätzlich 
unterschiedliche Vorgehensweisen in Bezug auf Titel und die Taktung der Beför- 
derungen zu Verwerfungen innerhalb der Projektteams führen könnten, was die 
Kooperation zwischen den beteiligten Standorten erschweren könnte: 


„Wir versuchen, sehr transparent die gleichen Wertmafsstabe anzulegen. 
[...] Sie müssen, wenn Sie eine globale Firma haben, versuchen, einen 
globalen Level zu haben, weil sonst kriegen Sie eine Diskrepanz in die 
Firma, die nicht funktioniert. Sonst kommt irgendwann die Situation: ich 
bin aber deutscher Projektleiter. Und ich glaube, das widerspricht dann all 
dem, was wir persönlich hören wollen. Das hatte ich mal - dann kriegen 
wir eine Farbe rein, die nicht gut ist.“ (NI6 - Hervorhebung durch den 
Gesprächspartner) 


Nun sind aber solch langsame Karrieren - hier als zeitliche Taktung der formellen 
Beförderungen verstanden - am indischen Standort nicht einfach durchzusetzen. 
Die arbeitsinhaltliche Motivation mag auch bei den indischen Beschäftigten sehr 
wichtig sein, doch sie sind auch an formellen Beförderungen interessiert, und 
wissen, dass sie diese durch einen Wechsel der Firma häufig bekommen können. 
Diese Erwartung ist nach Aussagen der interviewten Projektmanager in den 
indischen Teams durchaus präsent, wie der folgende Gesprächspartner kurz und 
bündig auf den Punkt bringt: 
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„If you don’t promote them - they will leave and go.“ (NI27) 


Daher steht NovoProd in Bezug auf ihre Beförderungspolitik im indischen Ent- 
wicklungszentrum unter starkem Druck. Die Erwartungen der Beschäftigten 
in Bezug auf Häufigkeit und Geschwindigkeit von Beförderungen werden vor 
allem von den (die indische IT-Industrie dominierenden) IT-Dienstleistungsun- 
ternehmen geprägt, doch NovoProd kann diesen Erwartungen als Produktfirma 
nicht gerecht werden, wie ein Personalmanager erklärt: 


„Most of the companies follow the same principle. I mean, people forget, 
that we are in a product company and not in a services company. Because 
in services company, you move from project to project, right? So, if the 
number of projects grows, then there can be more project managers, right? 
If the project is big, then I can have couple of module leads or small leads, 
right? But in product, I know, that my module within Application will 
be 30 people only. Right? So, I cannot make all of them lead. Yeah. And 
then, what happens, because of this reason, there is a lot of attrition, which 
happens. Say, if a person doesn’t get promoted after three years or three 
and a half years - then he tends to leave. Right? Because somebody is giving 
him a lead position somewhere. He will surely get, because there is a lot 
of demand in India. So he’ll surely get a better pay and that lead position 
somewhere else - so he will move out.“ (NI4) 


Der hier angesprochene „Vorteil“ der IT-Dienstleistungsunternehmen konnte bei 
ServiceTec gut verdeutlicht werden. Das Wachstum des Unternehmens beruht 
vor allem auf der zunehmenden Zahl der Kundenprojekte, und es ging mit 
einer ebenfalls rapide steigenden Zahl von nötigen Führungspositionen (Projekt- 
und Modulleiter) einher. So stellte es bei ServiceTec kein Problem dar, einen 
einigermaßen regelmäßigen Beförderungszeitraum von ca. 3 Jahren einzuhalten. 
Bei NovoProd ist die Situation jedoch anders. Die Größe der an der Entwicklung 
beteiligten Abteilung bis zur Fertigstellung des neuen Produkts weitgehend 
unverändert. Dies bedeutet, dass im Laufe der Entwicklung bei NovoProd nur 
wenige Führungspositionen neu zu besetzen sind, auf die Beschäftigte befördert 
werden könnten. Daher kann NovoProd mit den kurzen Zeiträumen und den 
Häufigkeiten der Beförderungen vor allem der IT-Dienstleister nicht mithalten: 


„Ein Inder, der bei NovoProd ist, [...] der muss [...] nach drei Jahren 
sagen können, dass er Manager ist. [...] Das ist erst mal ein Faktum. Und 
NovoProd tickt genau so nicht.“ (NI6) 


Auch eine Mitarbeiterin der HR-Abteilung konstatiert, „dass NovoProd nicht 
soweit wie z.B. indische Firmen [ist], was die Titel anbelangt.“ (NI 3). Wenn 
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daher Beschäftigte von NovoProd in ihren Freundeskreisen ihre Karrieren ver- 
gleichen, bleiben sie gegenüber ihren Freunden, die in anderen Unternehmen 
arbeiten und häufiger befördert werden, schnell zurück. Der daraus entstehen- 
de Gruppendruck führt auch bei dem im Folgenden zitierten Entwickler zu 
Unzufriedenheit: 


„Because I have my friends in different service companies. So it does also 
have to do with peer pressure. Imean, when you say that every two years 
or three years, they’re getting promoted. And then you feel: ‘what are you 
doing here?’ Yeah, I mean: Work is fine, but then, as I said - there is, like, 
different aspects.“ (NI7) 


Nach Lage der Interviews gibt es bisher noch keine kohärente Strategie bei Novo- 
Prod, mit diesem Problem organisatorisch umzugehen. Vielmehr changieren die 
von den verantwortlichen Personalmanagern ergriffenen Maßnahmen zwischen 
verschiedenen Ansätzen. 


So wird zunächst versucht, die Beschäftigten im indischen Entwicklungszentrum 
an die in Deutschland übliche Vorgehensweise zu gewöhnen. Indem man ihnen 
diese vorlebt, hofft man die Beförderungswünsche zu dämpfen, ohne Unzufrie- 
denheit zu erzeugen: 


„Das ist aber eine Wertvorstellung, die wir in NovoProd über die 70er, 
80er und 90er Jahre gepflegt haben, die auch eine gewisse Kultur in unser 
Arbeitsschema reingebracht hat, die wir nicht exportieren können. Ganz 
schwer. Sie können das den Leuten vorleben, die Leute können bemerken, 
dass sie noch so sehr Development Manager sein können, dass es ziemlich 
egal ist, was sie sagen, solange der Architekt da hinten nicht genickt hat. 
[...] Dann merken sie sich vielleicht, dass letztendlich die fachliche Kompe- 
tenz das meist entscheidende ist hier bei NovoProd - in der Entwicklung 
zumindest - in diesem Inner Circle.“ (NI6) 


Ferner finden sich aber auch Ansätze, die darauf abzielen, schnelle Beförderun- 
gen zu „simulieren“.Entgegen der vom Management formulierten Strategie, als 
globales Unternehmen auch global einheitliche Strukturen und Hierarchiestufen 
zu etablieren, werden im indischen Entwicklungszentrum doch einige Titel ver- 
geben, die es so im deutschen Hauptquartier nicht gibt, wie z.B. einen „Junior“- 
oder „Platinum“- Developer (zusätzlich zum mittlerweile auch im deutschen Mut- 
terhaus eingeführten „Senior“-Developer; NI 7), als weitere Ausdifferenzierungen 
der Entwicklerebene. Auch die in Indien vorfindliche Position des fachlichen 
Leiters gibt es in der deutschen Firmenzentrale so nicht (NI 1). Mit diesen neuen 
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Titeln gehen praktisch keine Unterschiede in der Verantwortung oder Funktion 
im Projektablauf einher (die Ausnahme ist der fachliche Leiter, der ein leicht 
anderes Rollenprofil aufweist als ein „einfacher“ Entwickler). Sie bieten Novo- 
Prod aber die Möglichkeit, formal häufiger befördern zu können und damit das 
Bedürfnis nach neuen Titeln bei den indischen Beschäftigten zu befriedigen. In 
dieselbe Richtung gehen auch Versuche, Beförderungswünschen durch kleine 
Belohnungen, Pokale oder ähnliche Elemente symbolischer Anerkennung zu 
begegnen: 


„Also es gibt wohl irgendwelche ‚Trophies‘und dann Dinge in Richtung 
‚Employee of the Month‘. Das sind jetzt nicht die Titel, aber wirklich so, 
dass das die Mitarbeiter, dass ihnen gezeigt wird, ok, sie sind wichtig. Es 
gibt Pokale, die dann auch wieder den Rang zeigen. Das heißt, man ist zwar 
noch nicht formal auf der Management-Stufe, aber man hat drei Pokale vor 
sich stehen und dadurch zeigt man eigentlich, dass man wichtig ist, oder 
sehr gute Arbeit leistet.“ (ND3) 


Zudem kann trotz aller Beteuerung von „globalen Standards“ konstatiert werden, 
dass NovoProd beim Takt der Beförderungen in Indien Kompromisse eingeht 
und - sofern Positionen vorhanden sind - wesentlich schneller befördert, als es 
im deutschen Mutterhaus üblich ist, so dass Beschäftigte mit wesentlich weniger 
Erfahrung in höhere Positionen aufsteigen als ihre deutschen Counterparts. Ob- 
wohl NovoProd nach Aussagen des höheren Managements durch ihre „globalen 
Standards“ gerade diese Ungleichheiten innerhalb der Projektteams zu vermeiden 
sucht, wird dieses Thema damit zwischen dem deutschen und dem indischen 
Teamteil relevant und sorgt für Unzufriedenheit bei den Beschäftigten beider 
Seiten. 

Auf der deutschen Seite fühlen sich Beschäftigte übergangen, wenn ein deut- 
scher Entwickler mit teilweise über 10 Jahren Berufserfahrung einem indischen 
Projektmanager mit 4 Jahren Berufserfahrung gegentibertritt: 


„Wir haben einfach das Problem, dass wir in Indien eine Schattenwirtschaft 
aufbauen. Da sind die - also eigentlich erwarten wir globale Standards. Aber 
bei uns in Deutschland, würde ich behaupten, hat ein Senior-Developer 
einfach mehr Erfahrung und mehr Wissen angesammelt als in Indien. Kann 
ja, geht ja auch nicht anders, wenn ich in Indien in anderthalb Jahren zum 
Senior-Developer werde, kann ich gar nicht das Wissen angesammelt haben, 
was dann einen Schiefstand darstellt, deswegen Schattenwirtschaft. Und 
natürlich bei den deutschen Developern, ja, Unmut auslösen kann. Wenn 
die sagen: Ok, ich bin noch Developer und hier, die Leute in Indien sind 
schon Manager oder sind auf einer Projektmanager-Ebene.“ (NI3) 
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Auch wenn diese Haltung in den Interviews an einzelnen Punkten durchschien, 
ist Neid auf die indischen Beförderungen bei den deutschen Beschäftigten jedoch 
nicht dominant. Vielmehr scheinen die deutschen Beschäftigten ihre indischen 
Counterparts nicht wirklich ernst zu nehmen, weil Titeln generell weniger Rele- 
vanz zugestehen und auch die indischen Beschäftigten in erster Linie nach ihrer 
Berufserfahrung beurteilen, wie die bereits zitierte HR-Beschäftigte vermutet: 


„Also es sind einfach andere Bedingungen, und ich denke, dass das Ver- 
ständnis größtenteils schon da ist. Also auf der emotionalen Ebene sagt 
man dann: Ok, das ärgert mich jetzt, weil ich eben diesen Titel habe. Aber 
einerseits sind wir in Deutschland nicht so titelversessen, das heißt, es ist 
eigentlich auch in Ordnung, wenn ich Developer bleibe. Da bricht jetzt 
nicht meine Familie zusammen oder ich werde ausgestoßen. Auf der an- 
deren Seite denke ich auch, kann man das akzeptieren, dass der andere ... 
Also man sieht es dann, was vielleicht nicht immer gut ist, wirklich als 
Schattensystem an, dass man sagt, dass sich ein Deutscher - und das sind 
jetzt wirklich nur Vermutungen - dass sich ein deutscher Entwickler sagt: 
Ok, eigentlich bin ich auf der Ebene, auf der indische Manager sind, und 
damit kann ich leben, und das ist einfach die Bezeichnung.“ (ND3) 


Mit dieser Vermutung liegt die HR-Beschäftigte nach Lage der Interviews durch- 
aus richtig, wie sich in der folgenden Aussage eines Personalmanagers im indi- 
schen Entwicklungszentrum deutlich zeigt: 


„Das [sein indischer Counterpart - PF] ist ein Projektmanager light. Also, 
das war zumindest meine Erfahrung. Es mag sich jetzt auch mittlerwei- 
le ein bisschen geändert haben. Aber, eh, als ich angefangen habe, muss 
ich für mich persönlich sagen, war die Erfahrung immer eigentlich: das 
war ein Projektmanager light - mit der Konsequenz, dass die Leute in 
Deutschland auch nicht so, so ernst genommen werden als Projektmanager. 
... Ist auch klar, eh, wenn man sich die Situation ... Ein Projektmanager 
in Deutschland hat, ich weiß nicht: 10, 11, 12 Jahre Erfahrung, Berufs-, 
NovoProd-Erfahrung, vielleicht sogar 15 Jahre Gesamtberufserfahrung. 
Auf jeden Fall also Leute, die wirklich wissen, wie man Projekte leitet und 
die das öfters unter Beweis stellen mussten, die einfach die Erfahrung haben. 
Und jetzt kommt hier ein Projektmanager mit vier Jahren Berufserfahrung. 
[...] Ich würde es auch nicht ernst nehmen, oder sagen wir mal so: Ich 
würde mit Sicherheit erst mal offen sein, weil ich von vornherein nicht 
jemand bin, der irgendwie Vorurteile da hat oder voreingenommen ist. 
Aber ich würde dann dem Ganzen schon kritisch gegenübergestellt sein 
und würde mir das auch anschauen. Und würde gucken: Ist es wirklich ein 
Projektmanager?“ (NI1) 


258 Fallstudie NovoProd 


Diese Nicht-Anerkennung der „indischen“ Jobbezeichnungen und Titel durch 
die deutschen Beschäftigten wird für die indischen Beschäftigten zum Problem, 
weil sie sich von ihren deutschen Counterparts nicht ernst genommen fühlen. 
Daher beklagen sie häufig die fehlende Anerkennung und den fehlenden Respekt 
für ihre Position. 

Die Bemühungen NovoProds, dem Wunsch der indischen Beschäftigten nach 
schnellen Beförderungen nachzukommen, war daher zum Zeitpunkt der Un- 
tersuchung ein konfliktreiches und daher auch auf Managementebene stark dis- 
kutiertes Thema. Daher erfordert es viel Fingerspitzengefühl der jeweiligen 
Vorgesetzten, mit den Karriereerwartungen von Beschäftigten angemessen umzu- 
gehen. Die folgende Passage zeigt, welche Kreativität von den Managern in dieser 
Hinsicht gefordert ist: 


„I mean our team is a mix of girls and guys. So there are five ladies right 
now in the team. And three of them are on maternity leave. So that will be, 
like, a little long - spanning from three months to nine months. [...] So, 
these people won’t ask for promotion, because they are on maternity leave. 
So they won’t be working for quite some time this year. [...] Then one of 
them has been promoted, which has not been announced as yet. So that 
takes care of this guy for next two years - at least two years. [...] So, one 
guy wanted to work from Germany for a year. So he spoke to VP [Vice 
President - PF], and VP spoke to his VP, and they got that approved. So, 
even if you don’t give a promotion, he is there for two years. Because he 
was in Germany for one year. He got, what he wanted. Right? So, without 
giving him promotion, you can keep him happy for two years. [...] Ok, 
one guy wants - I want to maintain somebody, right? So, if a guy joins my 
team - I’ll make him his mentor! He is happy for six months, yeah? Some 
guy wants to travel abroad, so I’ll speak to my VP, if he can travel there 
for two to three weeks. One trip, and he is happy for six months or one 
year. These are small things, which we have to take care - and these things 


work.“ (NI4) 


Die zitierte Aussage eines Personalmanagers zeigt deutlich, wie unterschiedlichste 
Anreize genutzt werden, um die Beschäftigten für ausbleibende Beförderungen 
zu entschädigen. Wenn solche Entschädigungen nicht verfügbar sind, besteht 
häufig nur noch die Möglichkeit, Beschäftigte hinzuhalten: 


Other thing is: you have to ... develop these guys through mentoring, 
coaching, train. To tell them, that to grow, you need to develop yourself. 
You need to shoulder extra responsibility. Right? For the two years, you 
have been working on something. That doesn’t give you a lead position. I 
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need to see, that you go out of your way to do something more than what 
has been given to you. So convince him that you have not done enough. 
“You have done 100 percent of your work - no doubt. You have been 
good in that, right? But you need to go beyond that to deserve the next 
position! Tell me, how many people love you: two of your colleagues and 
two in Germany. Right, because you have been working just with these 
two guys and these two guys - four, that’s all. Have you interacted with 
the VP directly or VP of some other area directly? Have you escalated 
a problem some time? Or have you dealt with escalation some time? So, 
these are things, you need to ... move to the next level!’ So, if you talk with 
them, you give them practical examples. You sit with them, try to explain 
your own position, their position. That they need to do extra to win that 
position ... So you can bargain for another year with these guys. [...] I mean, 
the thing is: I have been through all of this. So I know, how people behave 
and what they expect - and how you can set their expectations right.“ (NI4 
- Hervorhebung des Verfassers) 


Die Reduzierung von Fluktuation aufgrund enttäuschter Karriereerwartungen 
der Beschäftigten stellt also für NovoProd nach wie vor ein großes Problem dar, 
und die zitierte Aussage des Personalmanagers zeigt, wie bei NovoProd mit ganz 
unterschiedlichen Ansätzen versucht wird, dieses Problem anzugehen und die 
Beschäftigten dadurch in der Firma zu halten. 


Ein ganz ähnliches Problem stellt sich für NovoProd in Bezug auf die Entwick- 
lung der Gehälter im indischen Entwicklungszentrum (siehe Kapitel 3). Auf den 
ersten Blick scheint der Bereich der Gehälter bei NovoProd kein Problem zu 
sein, das Beschäftigte aus dem Unternehmen treibt. Alle Gesprächspartner, die 
vorher bei einer indischen Dienstleistungsfirma gearbeitet haben, berichten von 
erheblichen Gehaltssteigerungen durch den Eintritt bei NovoProd. Die Rede ist 
von 25 - 30% Zuwachs gegenüber ihrem vorherigen Gehalt. 

Die von der HR-Abteilung genannten und durch die Befragung der Entwick- 
ler bestätigten Zahlen zeigen, dass das Grundgehalt auf der Einstiegsebene bei 
NovoProd mit 42.000 - 52.000 Rupien (ungefähr 620 - 770 Euro) Bruttogehalt 
über 50% über dem bei ServiceTec liegt. Warum stellt die Gehaltsentwicklung 
für NovoProd dann dennoch ein Problem dar? 

Ein wichtiger Grund für finanzielle Unzufriedenheit von Beschäftigten liegt 
darin, dass NovoProd aufgrund seines Verlagerungsmodells nur in sehr seltenen 
Fällen Onsite-Postings vorsieht. Beschäftigte im indischen Entwicklungszentrum 
sind dort eingestellt und sollen auch primär dort arbeiten. Eine regelmäßige Rota- 
tion an Hochlohnstandorte, wie sie bei IT-Dienstleistungsunternehmen aufgrund 
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des speziellen Kundenkontaktes möglich sind, gibt es bei NovoProd daher nicht. 
Schließlich wäre jeder Wechsel eines Beschäftigten aus dem indischen ins deutsche 
Entwicklungszentrum mit erheblichen Kostensteigerungen verbunden, da dieser 
dann zu deutschen Konditionen beschäftigt werden müsste. So finden sich bei 
NovoProd zwar viele Beschäftigte, die zum Zweck eines bestimmten Trainings 
oder zum Kennenlernen der deutschen Kollegen eine Zeit lang im deutschen 
Entwicklungszentrum gewesen sind, doch dabei handelt es sich vorwiegend um 
zeitlich auf 3-4 Wochen befristete Aufenthalte. Eine längerfristige Beschäftigung 
im deutschen Entwicklungzentrum oder dem eines anderen Hochlohnstandortes, 
die finanziell lukrativ wäre, ist hingegen sehr selten. 

Zudem konnte im Abschnitt zur Kontrollstruktur bei NovoProd (Kapitel 
6.3.2) gezeigt werden, dass die variable leistungsbezogene Vergütung sich kaum 
monetär auswirkt. Berücksichtigt man nun außerdem das Problem der langsamen 
Beförderungen bei NovoProd, so lässt sich absehen, dass die Gehälter der Ent- 
wickler meist relativ langsam wachsen und sich zudem nicht stark voneinander 
unterscheiden. Denn wie im deutschen Hauptquartier arbeitet NovoProd auch im 
indischen Entwicklungszentrum mit (für jede Position) festgelegten Gehaltsbän- 
dern. Bei der Einstellung werden Entwickler (dies ist die Haupteintrittsposition 
bei NovoProd) in Abhängigkeit von ihrer relevanten Berufserfahrung in ein 
Gehaltsband eingeteilt, das ihr Grundgehalt bestimmt. In den Gehaltsverhand- 
lungen kann der zuständige Manager zwar ein wenig über den festgelegten Betrag 
hinausgehen, wenn ihm der Bewerber sehr wichtig ist, doch dies wird von der 
Personalabteilung nicht geschätzt, wie der im Folgenden zitierte HR-Vertreter 
klarstellt: 


„There is no range, it’s a fixed amount. So if you fall in the band of two to 
two and half years [Berufserfahrung - PF], this is exactly the salary, you 
get.“ (NI15) 


Auch die Schilderung des folgenden Entwicklers bestätigt diese Praxis: 


„I have friends, who have interviewed with NovoProd and some turned 
it down, because they felt, that there was no negotiation possible. It’s just 
your experience and your previous organization, your previous academic 
record, that decides.“ (NI21) 


Hintergrund ist auch in diesem Fall die ,internal parity“, die zwischen den 
Beschäftigten bei NovoProd hergestellt und aufrechterhalten werden soll (vgl. 
Kapitel 6.3.2), weil befürchtet wird, dass starke Gehaltsunterschiede das Klima in 
den Projektteams negativ beeinflussen könnten. 
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„But otherwise, we are very, very strict. Because otherwise, what will 
happen, is, to get people from the market, we offer them higher salaries and 
then it will create inference in the team, that we certainly don’t want. That 
is something, which used to happen in my previous organization. People 
used to be very unhappy, whenever a new person used to join us, because 
the new person would have high salaries.“ (NI15) 


Von daher verzichten Beschäftigte durch ihren Einstieg bei NovoProd auf nicht 
unerhebliche Gehaltsbestandteile, die bei anderen Unternehmen einen wesentli- 
chen finanziellen Anreiz darstellen. Die Frage, ob eine Beschäftigung bei Novo- 
Prod nun finanziell lukrativer ist als z.B. bei einem IT-Dienstleister, ist aus den 
genannten Gründen nicht klar zu beantworten und wird auch von den Beschäftig- 
ten sehr unterschiedlich eingeschätzt. Einige halten die Verdienstmöglichkeiten 
bei den Dienstleistungsunternehmen für höher, andere hingegen denken, dass das 
Grundgehalt bei NovoProd den Ausschlag dafür gibt, dass hier besser verdient 
würde. 

Zwar finden sich in den Interviews keine Klagen über die Höhe der aktuellen 
Gehälter. Allerdings wird kritisch angemerkt, dass die Entwicklung der Gehälter 
bei NovoProd Grund zur Sorge gibt, weil sich außerhalb NovoProds die Gehälter 
und Gehaltserwartungen von Beschäftigten äußerst rasant steigern. Zwar wurden 
im indischen Entwicklungszentrum (analog zu den Jobtiteln) die Gehaltsbänder 
für die einzelnen Jobtitel stärker differenziert als dies im deutschen Mutterhaus 
der Fall ist, um damit häufigere Gehaltserhöhungen möglich zu machen (vgl. 
NI15). Trotzdem wird z.B. von folgenden Gesprächspartner die Ansicht geäußert, 
dass NovoProd langsam den Anschluß an die Gehaltsentwicklung der Branche 
verliere: 


„NovoProd used to be a good pay-master. Not a good, but among the top 
pay masters ... till about two, three years back. But Ithink, we are now 
not keeping pace with the others. So we must be, say, 80 percent of... I 
mean [...] somebody, who is equivalent to me outside NovoProd might 
be getting, say, around 20 percent more than me or something like that.“ 


(NI13) 


Derselbe Befragte fiihrt diese Entwicklung auf die Entscheidungsstrukturen bei 
NovoProd zuriick: 


„I mean, historical reasons are, that NovoProd is ... hikes are decided in 
Germany. I think, the HR here ..., hm, there is a use case, saying: ‘ok, this is 
the market standard and this is, what we should pay’. And then NovoProd 
- the HR that decides - also takes into account, what has been NovoProd’s 
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performance over the year and what are the pay hikes there and all that. So 
I think it’s a combination of factors basically.“ (NI13) 


Diese Aussage wird von der HR-Beauftragten im deutschen Hauptquartier bestä- 
tigt (ND3). Tatsächlich werden die jährlich möglichen Gehaltserhöhungen zentral 
für alle an der Entwicklung beteiligten Projektteams im deutschen Hauptquar- 
tier festgelegt. Dazu wird für jeden Standort eine Summe bestimmt, um die die 
Gesamtgehaltssume im Jahr wachsen darf. An diese Vorgaben müssen sich die Per- 
sonalmanager bei NovoProd anschließend halten. Die erwähnte HR-Beauftragte 
bestätigt auch, dass in diese Festlegungen neben Studien zu standortspezifischen 
Gehaltsstandards auch Daten zur wirtschaftlichen Entwicklung des Gesamtun- 
ternehmens eingehen. Da NovoProd mit zunehmender Konkurrenz auf dem 
bedienten Marktsegment konfrontiert sei und daher bei der Entwicklung unter 
starkem Kostendruck stehe, sei die für Gehaltserhöhungen zugestandene Summe 
in den letzten Jahren nicht mehr so hoch gewesen, wie in den Jahren zuvor. 
Dies macht die Gehaltsfestsetzung im indischen Entwicklungszentrum für 
NovoProd zunehmend schwieriger. Denn der Grundsatz der „internal parity“ 
bezieht sich nicht nur auf die Gleichbehandlung aller Beschäftigten einer Stufe. 
Vielmehr darf auch die Gehaltsentwicklung inner- und außerhalb des Unter- 
nehmens nicht zu stark auseinanderfallen, wenn die „internal parity“ zwischen 
erfahrenen und neueingestellten Beschäftigten nicht verletzt werden soll. 


„Und was man natürlich auch nicht vergessen darf, ist: Wenn ich heute fünf 
Entwickler einstelle zu einer bestimmten Basıs oder zu einem bestimmten 
Gehalt eben, [...] das ist natürlich noch mal ganz anders, wenn ich, sagen 
wir mal, in ein, zwei Jahren dann wieder fünf Entwickler einstelle. [...] Ich 
muss im Prinzip also nur aufpassen, dass die fünf neuen Entwickler, die 
ich ein Jahr später einstelle, dass die vom Gehalt her die Entwickler von 
damals nicht überholen.“ (NI1) 


Entsprechend kann man die Gehaltssteigerungen, die außerhalb NovoProds üb- 
lich sind, nicht mitvollziehen - und Fluktuation nicht durch monetäre Anreize 
bekämpfen. Um dieses Problem zu umgehen, werden teilweise intern Gehaltser- 
höhungen vorgenommen, wie ein Personalmanager berichtet: 


„Da mussten wir eine Anpassung machen vor ein paar Jahren.[...] für die, 
die im Unternehmen waren: Die haben quasi noch mal etwas obendrauf 
gekriegt, weil das Wachstum der Gehälter am Markt einfach so rapide war, 
dass unser internes Wachstum da ein bisschen hinterher gehinkt ist, und 
man eben dann diesen Ausgleich vornehmen musste, weil sonst hätte man 
die Konsequenz gehabt, dass die Leute schlicht und ergreifend wegen Geld 
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gehen. Nur mal, um eine Zahl zu nennen: ein Entwickler verdient [...] 
sagen wir mal: 500 000 Rupees. [...] Das wäre sein Jahresgehalt. [...] Und 
ich kriege draußen, sagen wir mal, statt meinen [...] 500 000 kriege ich eben 
600 000. Und so signifikant sind unter Umständen die Unterschiede, je 
nach dem, wie sich der Markt entwickelt hat. Klar, dann gehe ich. Und das 
ist auch das Druckmittel, was die Leute dann hier auch haben [...] und wo 
man auch ab und zu mal drauf reagieren muss. Und eben aus dem Grund 
wurde diese Anpassung damals, diese außergewöhnliche Anpassung auch 
vorgenommen.“ (NI1) 


Die Schilderung des Managers zeigt sehr schön die Zwangslage, die hier für No- 
voProd entsteht. Die hohe Abhängigkeit von den Beschäftigten und deren daraus 
folgende Machtposition führt dazu, dass die Gehälter am indischen Standort 
außerplanmäßig erhöht werden mussten, um keine Beschäftigten aus finanzi- 
ellen Gründen an die Konkurrenz zu verlieren - und gleichzeitig werden die 
Gehaltsbudgets von der Zentrale limitiert. 

Der Bereich der Gehälter stellt also genauso wie der der Beförderungen für 
NovoProd eine große Herausforderung dar. Zwar werden die gegenwärtig bei 
NovoProd gezahlten Gehälter von den Beschäftigten noch als wettbewerbsfähig 
angesehen und größere Beschwerden bzgl. der finanziellen Situation wurden in 
keinem Interview erwähnt. Wie sich diese Situation jedoch in Zukunft entwickelt, 
ist offen, und es gibt einige Anzeichen, dass sich hier Probleme ergeben könnten, 
die finanziellen Erwartungen der Beschäftigten weiterhin zu erfüllen. 


Betrachtet man abschließend das in Kapitel 3.3 (S. 56) beschriebene Spannungsfeld 
von Reduzierung von bzw. Immunisierung gegen Fluktuation, so lässt sich zusam- 
menfassen, dass sich die bei NovoProd ergriffenen Maßnahmen vor allem darauf 
richten, Fluktuation zu reduzieren. Eine Immunisierung der Arbeitsabläufe ge- 
gen Fluktuation, die im wesentlichen darin bestehen würde, die Arbeitsabläufe 
stark zu standardisieren und zu formalisieren und damit die Abhängigkeit von in- 
dividuellen Wissens- und Erfahrungsbeständen zu reduzieren, stünde immerhin 
in einem schroffen Gegensatz zur strategischen Zielstruktur des von NovoProd 
angestrebten Verlagerungsmodells. 

Bei den Maßnahmen zur Reduzierung von Fluktuation setzt NovoProd strate- 
gisch vor allem auf arbeitsinhaltliche und -organisatorische Anreize, wohingegen 
die Bereiche der betrieblichen Karrieren und Gehälter für NovoProd eher Schwie- 
rigkeiten bergen. Zwar zeigen die (für den indischen Standort vergleichsweise 
niedrigen) Fluktuationsraten von 9%, bzw. 7,5% bei Application, dass diese Stra- 
tegie bisher erfolgreich ist, jedoch bergen die eher auf Beschäftigungsverhältnisse 
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bezogenen Aspekte der Beförderungen und Gehälter durchaus Probleme, die 
mittelfristig zu einem Anstieg der Fluktuationsraten führen könnten. Erste An- 
zeichen lassen sich in den Interviews finden. 

So gibt ein HR-Manager (NI16) an, dass sich die Fluktuationsraten bei Novo- 
Prod in den ersten Monaten des Jahres 2007 erhöht haben. Er beziffert diesen 
Anstieg auf 25-30% gegenüber den Vorjahren. 


„Last four, five years it’s [die Fluktuationsraten - PF] been much lower 
than the market. This year the indication is not so good. The kind of 
indication, that we got for the first three months is a lot worse than what 
we have seen in the past, from our internal benchmark. [...] It’s a terrible 
amount of pressure on that issue at this point in time. [...] I think, we’ll 
internally have to look at some things: 25, 30 percent worse than last year.“ 


(NI16) 


Erschwerend kommt hinzu, dass die von NovoProd beabsichtigte Zielstruk- 
tur bisher nur in jenen Bereichen weitgehend umgesetzt werden konnte, die in 
der Zusammensetzung stabil waren, wohingegen in den Teams, die stärker von 
Fluktuation betroffen waren, wesentlich restriktivere Maßnahmen der Arbeits- 
organisation und -kontrolle implementiert werden mussten. In den Teams, die 
restriktiver behandelt werden, sind auch die arbeitsinhaltlichen Anreize nicht so 
ausgeprägt wie in den stabilen Teams, was die Beschäftigten wiederum weniger 
stark an das Unternehmen bindet (u.a. NI9, NI15, NI22). Es zeigen sich hier 
also dynamische Wechselwirkungen - eine Art Teufelskreis - wie der folgende 
Gesprächspartner formuliert: 


„I hose guys, Germans, they cannot give very critical work, because they 
know, that: ‘ok, you don’t have the expertise’. And by the time somebody 
has this expertise, he will move out. And we also keep complaining, that 
we don’t get critical work or important work. So that’s why we try to 
emphasize that: ‘ok, you need to spend some time in NovoProd - three 
years, four years. And then only you start getting more important, critical...’ 
That’s why we try to retain people, and put a lot of stress on that.“ (NI4) 


Zum Zeitpunkt der Untersuchung war also in Bezug auf die Arbeitsmarktbe- 
ziehungen NovoProds noch vieles in Bewegung. Ähnlich wie für die anderen 
Aktivitätsfelder, kann daher konstatiert werden, dass NovoProd angesichts der 
indischen Verhältnisse vor großen Herausforderungen steht, die beabsichtigte 
Zielstruktur für ihre global verteilte Entwicklung zu realisieren. 
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6.4 Zusammenfassung und Bewertung der bei 
NovoProd verfolgten Kontrollstrategie 


NovoProd versucht, das indische Entwicklungszentrum als zentralen Teil seines 
globalen Entwicklungsnetzwerkes zu etablieren. Dafür spricht nicht nur die 
in den letzten Jahren zunehmende Personalstärke, die den indischen Standort 
mittlerweile zum zweitgrößten NovoProds weltweit macht. Darüber hinaus zeigt 
auch die Tatsache, dass in der untersuchten Einheit Application ein zentraler Teil 
des neuen Produkts hergestellt wird, die strategische Zielsetzung NovoProds, den 
indischen Standort keinesfalls als „verlängerte Werkbank“ für rein ausführende, 
arbeitsintensive Tätigkeiten zu nutzen. Vielmehr sollen die indischen Beschäf- 
tigten einen wichtigen, innovativen Beitrag bei der Entwicklung eines neuen 
Produktes leisten. Dementsprechend verfolgt NovoProd auch die Absicht, den 
indischen Standort und die dort lokalisierten Projektteams mit weitreichenden 
Verantwortlichkeiten hinsichtlich ihrer Aufgabenstellungen auszustatten - der 
bei NovoProd sogen. „Ownership“ für ihren Produktteil. 

Zwar lässt sich im Setup des globalen Entwicklungsnetzwerkes nach wie vor 
eine gewisse Asymmetrie feststellen, was die Verteilung von planenden und 
ausführenden Tätigkeiten angeht, und auch die technologische Komplexität des 
in Application zu bearbeitenden Moduls des Produkts ist etwas geringer einzu- 
schätzen als bei Tätigkeiten der im deutschen Hauptquartier situierten Einheit 
Plattform. Dennoch weisen auch die Application zugewiesenen und von ihnen 
verantworteten Aufgaben ein hohes Maß an Komplexität auf, was sowohl die 
qualifikatorischen Anforderungen an die beteiligten Entwickler, als auch die In- 
terdependenzen zu den anderen an der Entwicklung beteiligten Einheiten Vision 
und Plattform betrifft. 


Betrachtet man die Aktivitäten des Managements im indischen Entwicklungs- 
zentrum, so fällt auf, dass NovoProd strategisch dort primär auf permissive 
Kontrollstrategien setzt. Zwar ging selbst bei NovoProd die zunehmende Interna- 
tionalisierung der Produktentwicklung mit einer Tendenz zur Standardisierung 
und Formalisierung einher, um die global verteilt stattfindende Produktion und 
die damit notwendige, standortübergreifende Kommunikation und Kooperation 
der beteiligten Akteure zu strukturieren. Anders als bei ServiceTec, richtet sich 
diese Standardisierung und Formalisierung jedoch nicht zentral auf die zuneh- 
mende bürokratische Durchdringung des Arbeitsprozesses, sondern beinhaltet 
hauptsächlich Standards und formelle Vorgaben hinsichtlich der Produktarchi- 
tektur und des -designs. Um die verteilte, parallele Entwicklung des Produkts 
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zu gewährleisten, sind zwischen den einzelnen (an verschiedenen Standorten 
konzentrierten) Modulen klar definierte Schnittstellen erforderlich, die für die 
beteiligten Entwickler Rahmenparameter bei der Arbeit an ihrem jeweiligen Mo- 
dul darstellen. Innerhalb der Module stellen die Selbstorganisationsfähigkeiten 
der Beschäftigten jedoch, wie am Beispiel von Application gezeigt werden konnte, 
eine ganz zentrale Ressource für die Organisation der Arbeitsabläufe dar. 

Dies zeigt sich im Charakter der den Entwicklern zugewiesenen Arbeitspakete. 
Es konnte gezeigt werden, dass es sich im wesentlichen um integrierte Arbeitsauf- 
gaben handelt, die jeweils alle Phasen des Software-Lifecycles (wenn auch nur für 
einen Teil des Produkts) enthalten. Dementsprechend sind die von den Entwick- 
lern zu erledigenden Aufgaben zeitlich umfangreich bemessen und changieren 
innerhalb jeder Wave stark zwischen eher planend-konzeptionellen und eher 
ausführenden Tätigkeiten. Zudem treten aufgrund des stark interdependenten 
Charakters der Module im Zuge der parallel ablaufenden Entwicklung des Ge- 
samtproduktes permanent Störungen und Komplikationen im Bearbeitungsvor- 
gang auf, was von den Beschäftigten eine flexible und kreative Herangehensweise 
erfordert. 

Gerade dieser Charakter der im indischen Entwicklungszentrum geleisteten 
Arbeit ist nach Ansicht vieler Gesprächspartner auch der Grund, warum ei- 
ne weitreichende Standardisierung und Formalisierung der Arbeitsprozesse bei 
NovoProd nicht gewünscht, sondern vielmehr geradezu als Gefahr - als „Büro- 
kratiemonster“ - angesehen wird. Dementsprechend konnte in Bezug auf die 
bei NovoProd vorfindliche Form der Kontrollstruktur konstatiert werden, dass 
formalisierte Vorgaben in Form von Prozessbeschreibungen und Guidelines eher 
eine untergeordnete Rolle spielen. Vielmehr werden die Beschäftigten, sofern sie 
selber nicht die nötige Erfahrung besitzen, um ihre Aufgaben eigenständig zu 
planen und zu bearbeiten, oder bei Problemen und Unklarheiten, von erfahrene- 
ren Kollegen persönlich angeleitet. Die Aufgaben für die Entwickler werden zu 
Beginn jeder Wave wenig detailliert vorspezifiziert, und nur im Notfall werden 
vom jeweiligen fachlichen Vorgesetzten detailliertere Vorgaben gemacht. 


Um dennoch den Arbeitsprozess überblicken und in Problemfällen schnell ein- 
greifen zu können, wird der Fortschritt der Entwicklung formell in wöchent- 
lichen Sitzungen und informell durch die stetige Präsenz der fachlichen Vorge- 
setzten am Arbeitsplatz eng überwacht. Der Fokus ist dabei in erster Linie auf 
das Arbeitsergebnis gerichtet, nicht auf den Prozess der Bearbeitung. So wer- 
den für die zu entwickelnden Screens klare Anforderungen (in Form von sogen. 
„Use-Cases“, also definierten Einsatz-Szenarien mit spezifischen Funktionsanfor- 
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derungen) formuliert, denen diese am Ende entsprechen müssen. Das jeweilige 
Vorgehen soll aber den Entwicklern selbst überlassen bleiben. 

Zudem ist bei NovoProd die Bewertung von Arbeitsleistung wesentlich we- 
niger individualisiert, als dies bei ServiceTec der Fall war. Zwar gibt es auch 
individuelle Zielvereinbarungen, diese sind aber weniger formalisiert und de- 
tailliert, und bei der Bewertung der individuellen Zielerreichung wird der ko- 
operative Charakter der Aufgabenbearbeitung berücksichtigt. Die individuellen 
Leistungsbewertungen werden vertraulich behandelt und setzen sich kaum in 
Gehaltsunterschiede zwischen den Teammitgliedern um. Vielmehr wird bei No- 
voProd die „internal parity“ betont und versucht, keine Unstimmigkeiten durch 
Ungleichbehandlung innerhalb der Teams zu erzeugen, weil befürchtet wird, dass 
dies die Kooperation sowohl innerhalb der Teams, als auch standortübergreifend 
gefährden könnte. 


Der in dieser Form der Leistungsbeurteilung schon anklingende Versuch, den 
Teamgedanken zu betonen, ist auch kennzeichnend für NovoProds Gestaltung 
der internen Kooperations- und Kommunikationsbeziehungen. Sowohl am jewei- 
ligen Standort, als auch standortübergreifend sollen die Beschäftigten innerhalb 
des Entwicklungsnetzwerkes möglichst eng, direkt und multilateral miteinander 
kooperieren. Die Kommunikation wird nicht in bestimmten Positionen kon- 
zentriert und damit kanalisiert, sondern alle Entwickler sind aufgerufen, ihre 
deutschen bzw. indischen Counterparts möglichst direkt zu kontaktieren und 
sich die jeweils benötigte Information und/oder Unterstützung zu holen. Als 
Grund wird von den Gesprächspartnern auch der stark interdependente Charak- 
ter der Arbeit angeführt, der starke Kommunikationsnotwendigkeiten schaffe, 
die nicht in einzelnen Personen zu bündeln seien. 

Um multilaterale Kooperation zu ermöglichen und zu fördern, versucht No- 
voProd gezielt, alle Beschäftigten - auch standortübergreifend - miteinander in 
Kontakt zu bringen und somit die Etablierung von persönlichen Netzwerken 
zu erleichtern. Formalisierte Kommunikationskanäle und -formen sind daher 
bei NovoProd nicht geschätzt. Vielmehr wird nach wie vor der direkte, persön- 
liche Kontakt der Beschäftigten als wichtige Voraussetzung einer gelingenden 
standortübergreifenden Kooperation angesehen. 


Allerdings stößt NovoProd bei der Umsetzung der skizzierten Zielstruktur am 
indischen Standort auf größere Schwierigkeiten. So benötigt NovoProd eine sehr 
stabile Teamzusammensetzung, damit sich die Beschäftigten einerseits tief in ihre 
Arbeitsaufgaben einarbeiten und das nötige Erfahrungswissen aufbauen und an- 
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dererseits die wichtigen persönlichen Kontakte zu ihren deutschen Counterparts 
knüpfen können. Gerade diese Stabilität der Teamzusammensetzung herzustellen, 
ist allerdings im indischen Bangalore (anders als im deutschen Mutterhaus) eine 
herausfordernde Aufgabe. Zwar genießt NovoProd als multinationaler Produkt- 
Hersteller - hinsichtlich der Qualität der Arbeit, des Markennamens und des 
damit zusammenhängenden Prestiges - großes Ansehen, was dazu führt, dass 
zum Zeitpunkt der Untersuchung Rekrutierungen - auch aufgrund der ver- 
gleichsweise moderaten Wachstumspläne - am indischen Arbeitsmarkt nach wie 
vor unproblematisch waren. Beschäftigte jedoch längerfristig im Unternehmen 
zu halten, ist auch für NovoProd alles andere als einfach. 

Im Gegensatz zu ServiceTec setzt NovoProd dabei vor allem auf (aus dem spe- 
zifischen Verlagerungsmodell folgende) arbeitsinhaltliche und -organisatorische 
Anreize. So wissen es die indischen Beschäftigten sehr zu schätzen, dass ihnen 
bei NovoProd zur Bearbeitung ihrer Arbeitsaufgaben große Handlungs- und Ver- 
antwortungsspielräume eingeräumt werden. Doch obwohl diese bei NovoProd 
sehr präsente arbeitsinhaltliche Motivation grundsätzlich dazu führt, dass die 
Beschäftigten aufgrund ihrer Job-Zufriedenheit längerfristig im Unternehmen 
verbleiben (wollen), bestehen sie auf guten Karrierechancen, sowohl hinsichtlich 
Beförderungen und schnellem Aufstieg, als auch hinsichtlich guter Gehälter und 
entsprechender Erhöhungen. 

Ein globales Entwicklungsnetzwerk mit entsprechend enger Kooperation 
zwischen den eingebundenen Standorten macht es nun erforderlich, auch über 
die Standorte hinweg die „internal parity“ nicht zu stark zu verletzen. Die hohen 
Erwartungen der indischen Beschäftigten werden daher bei NovoProd stets in ein 
Verhältnis zu anderen Standorten gesetzt, an denen andere Bedingungen gelten. So 
erfolgen Beförderungen bei NovoProd im indischen Entwicklungszentrum zwar 
wesentlich schneller, als dies im deutschen Hauptquartier der Fall ist, und auch die 
Zahl der Jobtitel ist inoffiziell etwas höher, doch an die (den indischen Standort 
dominierenden) Standards der indischen IT-Dienstleister reicht NovoProd damit 
nicht heran. 

Auch über die Höhe der jährlich möglichen Gehaltssteigerungen wird bei No- 
voProd zentral unter Berücksichtigung aller beteiligten Entwicklungsstandorte 
entschieden. Dabei findet die spezifische Situation in Indien besondere Berück- 
sichtigung, doch trotzdem bleiben die Gehälter bei NovoProd zunehmend hinter 
dem Branchendurchschnitt zurück. 

Daher ist die gegenwärtige Situation bei NovoProd mit Fluktuationsraten, die 
mit knapp 7,5% bei Application deutlich unter dem Branchenschnitt liegen, zwar 
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noch vergleichsweise gut, jedoch zeigen sich erste Anzeichen dafür, dass sich die 
Situation zukünftig zuspitzen könnte. 

Angesichts der Form der Arbeitsorganisation im indischen Entwicklungszen- 
trum wäre eine solche Entwicklung für NovoProd sehr kritisch, weil durch die 
hohe Relevanz von individuellem Erfahrungswissen eine starke Abhängigkeit 
der Arbeitsprozesse von den Beschäftigten besteht. Daher ist der effektive Ablauf 
der Arbeitsprozesse durch erhöhte Fluktuation gefährdet. 

Schon gegenwärtig zeigt sich in den Teams, die in letzter Zeit mit erhöhter 
Personalfluktuation zu kämpfen hatten, wie stark sich dies auf die Form der 
Arbeitskontrolle am indischen Standort auswirkt: entgegen der strategischen 
Absicht, muss NovoProd in jenen Teams auf wesentlich restriktivere Formen der 
Arbeitskontrolle zurückgreifen und hat große Schwierigkeiten, die beabsichtigte 
Zielstruktur zu realisieren. Die in diesen Teams angewandten Elemente einer 
eher restriktiv wirkenden Form der Kontrolle sind dementsprechend jedoch 
nicht Ausdruck eines die Internationalisierung quasi automatisch begleitenden 
Industrialisierungsdrucks, sondern vielmehr Folge spezifischer Bedingungen am 
indischen Standort, mit denen die von NovoProd verfolgte Kontrollstrategie 
teilweise in Konflikt gerät. 


7 Zusammenführung und Ausblick: 
Die heterogene Reorganisation von 
IT-Arbeit im Zuge ihrer 


Internationalisierung 


Die vorliegende Studie hatte ihren Ausgangspunkt in der Frage nach veränderten 
Formen der Arbeitsorganisation und -kontrolle von IT-Arbeit im Zuge ihrer 
zunehmenden Internationalisierung. Im Gegensatz zu den Vertretern der „Indus- 
trialisierungsthese“ ging die vorliegende Arbeit nicht davon aus, dass die Reor- 
ganisation der Arbeitsprozesse in international operierenden IT-Unternehmen 
mit dem Begriff der „Industrialisierung“ angemessen beschrieben werden kann. 
Vielmehr wurde argumentiert, dass sich statt klarer Industrialisierungstendenzen 
in der IT-Industrie vielmehr unterschiedliche Reorganisationsmodi identifizieren 
lassen, innerhalb derer die weitreichende Standardisierung und Formalisierung 
der Arbeitsprozesse eine Möglichkeit darstellt, mit den Herausforderungen global 
verteilter Arbeitsprozesse umzugehen. Diese unterschiedlichen Reorganisations- 
modi, so das Argument weiter, beruhen auf den von den Unternehmen jeweils 
verfolgten Internationalisierungswegen und dem Zusammenspiel dieser Interna- 
tionalisierungswege mit zentralen Bedingungen der Standorte. 


In einem ersten Schritt zur Begründung dieser These wurde unter Berücksichti- 
gung der je spezifischen Form der Internationalisierung eines IT-Dienstleistungs- 
unternehmens und eines Standardsoftware-Herstellers argumentiert, dass sich die 
Unterschiede zwischen der jeweiligen Form der Internationalisierung (Captive 
Offshoring vs. Offshore-Outsourcing), die sich auf die spezifischen Geschäftsmo- 
delle zurückführen lassen, auf die Form und die Reichweite der von den jeweili- 
gen Unternehmen betriebenen Standardisierungsbemühungen auswirken. Mit 
Prozess- und Produktstandardisierung konnte dabei ein grundlegender Unterschied 
in den Standardisierungsbemühungen der beiden untersuchten Unternehmen 
charakterisiert werden. 
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In einem zweiten Schritt wurde der in dieser Studie im Zentrum stehende IT- 
Standort Indien in Bezug auf seinen Einfluß auf die (Re-)Organisationsmodi von 
Arbeit untersucht. Als zentraler Aspekt wurden die hohen Fluktuationsraten 
in der indischen IT-Industrie hervorgehoben, die aus deren explosionsartigem 
Wachstum in den letzten Jahren und einem damit einhergehenden Fachkräfteman- 
gel auf dem indischen Arbeitsmarkt folgen. Es wurde argumentiert, dass obwohl 
der indische Arbeitsmarkt für beide im Rahmen dieser Studie untersuchte Fälle 
gleichermaßen eine Herausforderung darstellt, die Wirkung der Arbeitsmarktsi- 
tuation auf die Reorganisationsmodi nicht eindeutig ist. Vielmehr wurde gezeigt, 
dass der indische IT-Arbeitsmarkt unterschiedliche Strategien des Umgangs er- 
möglicht, die in der begrifflichen Entgegensetzung von Immunisierung gegen 
und Reduzierung von Fluktuation idealtypisch gefasst wurden. 


In den beiden präsentierten Fallstudien schließlich wurden die beiden Faktoren 
zusammengebracht und empirisch belegt, wie sich aus dem Zusammenspiel von 
variierenden Internationalisierungswegen und indischem Arbeitsmarkt ein je 
spezifischer (Re-)Organisationsmodus von Arbeit in den indischen Entwicklungs- 
zentren beider Unternehmen herausbildet. Das Hauptaugenmerk der Fallstudien 
lag auf der Frage, inwiefern die Arbeitsprozesse in den beiden berücksichtigten 
Konstellationen jeweils „industrialisiert“ sind. Industrialisierte Arbeitsprozesse 
wurden dabei als Formen der Arbeitskontrolle interpretiert, die mit Friedman 
als Formen der „direkten“ Kontrolle gefasst werden können. Ein an Friedman 
angelehntes Analysemodell bot die Möglichkeit, die vorfindlichen Formen der 
Arbeitskontrolle anhand der Aktivitäten des Managements in vier zentralen 
Aktivitätsfeldern zu beschreiben und anhand ihrer strategischen Dimensionen in 
Bezug auf ihren Grad an Restriktivität zu vergleichen. Es konnten dabei in allen 
untersuchten Aktivitätsfeldern wesentliche Unterschiede zwischen den beiden 
Fällen herausgearbeitet werden. 

Der Fall ServiceTec entspricht dabei weitgehend den Erwartungen der Vertreter 
der Industrialiserungsthese. Ganz explizit wird hier vom Management die weit- 
gehende Standardisierung und Formalisierung der Arbeitsprozesse angestrebt 
und vorangetrieben. Für die Entwickler bedeutet dies, dass sie bei ServiceTec 
mit sehr kurztaktigen und hochgradig vorspezifizierten Arbeitsaufgaben kon- 
frontiert sind, die ihnen nur in sehr geringem Maße Selbstorganisations- und 
Problemlösungsfähigkeiten abverlagen. Zudem sind ihre Möglichkeiten, die Art 
und Weise der Bearbeitung ihrer Arbeitsaufgaben mitzubestimmen, durch eine 
ausgefeilte und detaillierte Kontrollstruktur stark eingeschränkt. Die bei Service- 
Tec präferierte Bezeichnung der Entwickler als „Ressources“ versinnbildlicht die 
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Rolle, die den Entwicklern bei ServiceTec zugewiesen wird: die Beschäftigten 
sollen möglichst flexibel und in jeder Position gleichermaßen einsetzbar sein. Um 
diesen Zustand zu erreichen, durchlaufen alle Beschäftigten gleichermaßen das 
firmeneigene, intensive Trainingsprogramm. Im Anschluß werden sie je nach Ge- 
schäftsaufkommen innerhalb der Firma eingesetzt und zudem stetig rotiert, um 
Spezialisierungseffekte auf bestimmte Kunden, Technologien oder auch Kunden- 
regionen zu verhindern und damit die Flexibilität des Personaleinsatzes aufrecht 
zu erhalten. 

Bei NovoProd hingegen wird auch im indischen Entwicklungszentrum stark 
auf die Selbstorganisationsfähigkeiten der Beschäftigten gebaut. Strategisches 
Ziel ist hier, die Beschäftigten soweit wie möglich zu befähigen, ihre - häufig 
lediglich grob vorspezifizierten und zeitlich langfristig bemessenen - Arbeitsauf- 
gaben eigenständig zu erledigen und etwaige Probleme auch selbständig zu lösen, 
ohne umfangreiche Anweisungen oder Vorgaben hinsichtlich der Bearbeitung 
zu benötigen. Ganz explizit findet sich hier die Absicht, Beschäftigte fachlich 
zu spezialisieren und tief einzuarbeiten, um die individuelle Leistungsfähigkeit 
bei bestimmten Tätigkeiten zu steigern. Zwar wird auch bei NovoProd zuge- 
standen, dass eine gewisse Standardisierung nötig ist, um die global verteilte 
Produktentwicklung zu koordinieren. Diese Standardisierung bezieht sich jedoch 
primär auf die Architektur und das Design des Produkts und die dazu nötigen 
Komponenten. So gibt es klare Vorgaben hinsichtlich des grafischen Designs 
und der Schnittstellen zwischen den einzelnen Modulen, die für die Entwickler 
im indischen Entwicklungszentrum nur unter besonderen Umständen zu verän- 
dern sind. Die Standardisierungsbemühungen von NovoProd richten sich nicht 
darauf, die Handlungs- und Verantwortungsspielräume sowie die Abhängigkeit 
der Arbeitsabläufe von den Beschäftigten möglichst weitreichend zu reduzieren. 
Der Devise Service Tecs, dass Projekte stets „process-depending and not people- 
depending“ sein sollten, stellt NovoProd vielmehr explizit einen „people-centric 
approach“ entgegen. 

Deutlichster Ausdruck dieses Ansatzes ist die Relevanz, die bei NovoProd 
dem direkten und persönlichen Kontakt aller Beschäftigten untereinander beige- 
messen wird. So ist die Kommunikation und Kooperation innerhalb des Teams 
nicht nur für die Bearbeitung auch der individuellen Arbeitsaufgaben unerläss- 
lich, sondern die Relevanz des direkten Kontakts wird auch im Rahmen der 
standortübergreifenden Kooperation vom Managament bei NovoProd stark 
betont. Nach Angaben der Gesprächspartner sei die Kooperations- und Kom- 
munikationsintensität zwischen den an der Entwicklung beteiligten Teilen des 
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Entwicklungsnetzwerkes derart stark, dass eine Kanalisierung der Kommuni- 
kation über bestimmte Personen eher hinderlich als förderlich wäre. So ist die 
gegenwärtig noch bestehende Aufgabe der Brückenköpfe, im Falle von noch nicht 
eingespielten persönlichen Kontakten zwischen den beteiligten Teamteilen als 
Informationsverteiler zu fungieren, auch lediglich als Notlösung zu verstehen, 
die langfristig abgeschafft werden soll. 

ServiceTec hingegen versucht, die Rolle des Entwicklers eher als „individual 
contributor“ denn als Teamplayer zu gestalten. Diese Absicht zeigt sich bereits in 
der Art der Aufgabenzuweisung, die ausschließlich Einzelarbeit an individuell 
zugeteilten Arbeitspaketen vorsieht. Auch darüber hinaus wird versucht, die 
Kommunikation und Kooperation über die unmittelbaren Ansprechpartner des 
Moduls hinaus möglichst zu kanalisieren. So kommunizieren die Beschäftigten 
im indischen Entwicklungszentrum meist nur über die jeweiligen Modulleiter 
mit anderen Teams oder mit den Beschäftigten beim Kunden. Der deutlichste 
Indikator für die geringere Relevanz, die bei ServiceTec der teamförmigen Ko- 
operation der Entwickler untereinander beigemessen wird, ist jedoch das System 
der Leistungsmessung und -beurteilung. Im Gegensatz zu NovoProd wird bei 
ServiceTec die Bewertung individueller Arbeitsleistung stark betont und gezielt 
versucht, die Entwickler miteinander um die besten Bewertungen konkurrieren 
zu lassen. 

Schließlich konnten auch wesentliche Unterschiede in den Arbeitsmarktbe- 
ziehungen von Service Tec und NovoProd nachgewiesen werden. Obwohl beide 
Unternehmen in Indien aktiv und damit grundsätzlich mit den gleichen Bedin- 
gungen konfrontiert sind, konnte dennoch gezeigt werden, dass sich die Strategien 
NovoProds und Service Tecs geradezu komplementär zueinander verhalten: Ser- 
viceTec fokussiert in seinen Rekrutierungsbemühungen vor allem auf die Stufe 
der Berufseinsteiger und rekrutiert daher gezielt Absolventen direkt von den 
Universitäten in Form von sogen. „Campus-Placements“. Aufgrund des starken 
Wachstums der letzten Jahre nehmen diese Einstellungen bei ServiceTec die Form 
von regelrechten Massenrekrutierungen an. Da das Angebot an fachlich auf IT 
spezialisierten Uniabsolventen zunehmend knapper, umkämpfter und damit 
auch teurer wird, ist Service Tec in den letzten Jahren dazu übergegangen, auch 
Absolventen nicht IT-naher Studiengänge als Zielgruppe zu erschließen. Ein 
ambitioniertes firmeninternes Einstiegstraining bietet Service Tec dabei die Mög- 
lichkeit, eine große Zahl neu rekrutierter Beschäftigter in kurzer Zeit mit den 
notwendigen Qualifikationen auszustatten. Demgegenüber rekrutiert NovoProd 
gar nicht auf der Ebene der Berufseinsteiger, sondern konzentriert sich auf die 
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Einstellung berufserfahrener Beschäftigter, die ihre ersten Jahre meist bei indi- 
schen IT-Dienstleistern verbracht haben. Die qualifikatorischen Anforderungen 
an die Beschäftigten sind bei NovoProd im Vergleich zu ServiceTec höher. So re- 
krutiert NovoProd bisher ausschließlich Absolventen IT-naher Studiengänge der 
100 renommiertesten Lehrinstitutionen Indiens. Die geringere Zahl benötigter 
Arbeitskräfte ermöglicht es NovoProd gegenwärtig noch, auf Massenrekrutie- 
rungen zu verzichten, und gezielt für offene Stellen zu rekrutieren. 

Der interne Personaleinsatz ist bei ServiceTec strategisch darauf ausgerichtet, 
die Beschäftigten nach der Einstellung möglichst lange flexibel einsetzbar zu 
halten. Konkret ist damit der Versuch gemeint, die Beschäftigten, nachdem sie 
das firmeninterne Training relativ homogen geschult verlassen haben, auch in 
den ersten Jahren des Einsatzes im Projektgeschäft möglichst gleichmäßig wei- 
terzuentwickeln. Vermieden werden sollen explizit Spezialisierungseffekte bei 
den Beschäftigten in Bezug auf bestimmte Technologien, Kundenbranchen oder 
-regionen. Auf diese Weise können Beschäftigte auf der Ebene der Entwickler 
ohne längere Einarbeitungszeiten zwischen Projekten versetzt werden, und die 
Projekte daher auch flexibel je nach Personalbedarf skaliert werden. NovoProd 
versucht hingegen, die Beschäftigten in bestimmten Tätigkeitsfeldern zu spezia- 
lisieren und die Projektteams möglichst stabil zu halten, damit die Entwickler 
wichtiges Erfahrungswissen und die notwendigen persönlichen Netzwerke inner- 
halb des Unternehmens aufbauen können. 

Aus diesen jeweils verfolgten Ansätzen folgt damit auch, dass die Abhängigkeit 
von den Beschäftigten auf der Ebene der Entwickler bei ServiceTec und Novo- 
Prod höchst unterschiedlich ist. ServiceTec betreibt große Anstrengungen, die 
Abhängigkeit der Projekte von einzelnen Beschäftigten möglichst weitreichend 
zu reduzieren. Dies dient einerseits dem flexiblen Einsatz der Beschäftigten in 
Projekten mit wechselndem Personalbedarf, andererseits aber auch einer Immu- 
nisierung der Arbeitsprozesse gegen die am indischen Standort herrschenden 
hohen Fluktuationsraten. So kann ServiceTec nach eigenen Angaben den Ausfall 
eines Teammitglieds in ca. 3 Wochen personell ausgleichen. NovoProd hingegen 
treffen Kündigungen von Teammitgliedern wesentlich härter. Auf der einen Sei- 
te sind die Einarbeitungszeiten bei NovoProd mit von den Gesprächspartnern 
geschätzten 3-6 Monaten wesentlich länger und auf der anderen Seite gibt es bei 
NovoProd auch keine „Bank“!, wie sie bei ServiceTec existiert. So müssen für 


1 Damit ist das Vorgehen ServiceTecs gemeint, Beschäftigte, die zu einem Zeitpunkt keinem 
Projekt zugeordnet sind, bis zur Zuweisung in ein Projektteam mit grundlegenden Weiterqua- 
lifizierungsarbeiten zu betrauen. Als Sprachgebrauch hat sich für diese Übergangsphase bei 
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Personen, die die Firma verlassen, häufig neue Beschäftigte extern rekrutiert wer- 
den, was der Einarbeitungszeit häufig noch weitere Monate für die Rekrutierung 
hinzufügt. Dementsprechend stellen die hohen Fluktuationsraten für NovoProd 
eine größere Gefahr dar, und es konnte gezeigt werden, wie die Personalfluktu- 
ation bei NovoProd dazu führte, dass zentrale Elemente der organisatorischen 
Zielstruktur in einigen Teams bisher nicht verwirklicht werden konnten. 


Fasst man die in den einzelnen Aktivitätsfeldern konstatierbaren Unterschiede 
zwischen ServiceTec und NovoProd zusammen, so lässt sich also konstatieren, 
dass ServiceTec in seinem indischen Entwicklungszentrum stark auf restriktive 
Formen der Arbeitsprozesskontrolle setzt. Bei NovoProd ließen sich hingegen 
wesentliche Elemente von permissiven Formen der Kontrolle identifizieren, 
wenngleich auch NovoProd gezwungen ist, in einigen Teams wesentlich restrikti- 
ver vorzugehen, als es die strategische Zielstruktur vorgab. 


Aus den präsentierten Ergebnissen lassen sich zwei zentrale Befunde herausheben, 
die für die Debatte über die Veränderungen der Arbeitssituation von Beschäf- 
tigten im Zuge der zunehmenden Internationalisierung der IT-Industrie von 
besonderem Interesse sind. 


7.1 Zwischen Wissensarbeit und Industrialisierung - 
Zur Entwicklung von IT-Arbeit im Zuge ihrer 
Internationalisierung 


Die Ergebnisse dieser Studie bestätigen, dass in der IT-Industrie große Verände- 
rungen in der Organisation der Arbeitsprozesse im Zuge ihrer zunehmenden 
Internationalisierung stattfinden. Die Untersuchung der Formen der Arbeitsor- 
ganisation und -kontrolle bei ServiceTec hat gezeigt, dass die Internationalisierung 
durchaus mit einer weitreichenden „Industrialisierung“ der Arbeitsprozesse ein- 
hergehen kann, wie die Vertreter der „Industrialisierungsthese“ betonen. Die 
Formen der Arbeitskontrolle bei ServiceTec stellen gegenüber dem, was tradi- 
tionell über die Form der Kontrolle von IT-Arbeit in der Literatur geschrieben 
wird, ein gänzlich neues Vorgehen dar. In Form seines „Global Delivery Model“ 


Service Tec eingebürgert, dass sich diese Beschäftigten in der Zeit auf der „Bank“ befänden. Die 
Bank ist daher ein firmeninterner Arbeitsmarkt, auf den Beschäftigte je nach Projekterfordernis- 
sen flexibel freigesetzt und von dem sie ebenso auch wieder in die Projektteams aufgenommen 
werden können (vgl. Kapitel 5.3.4). 
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hat ServiceTec einen Ansatz gefunden, die globalen Arbeitsprozesse mithilfe 
standardisierter und formalisierter Prozessbeschreibungen zu durchdringen und 
die Beschäftigten damit extrem restriktiven Formen der direkten Kontrolle zu 
unterwerfen. Entgegen den Ansichten jener Autoren, denen die Selbstorgani- 
sationsfähigkeiten und die hohen Autonomiespielräume der Beschäftigten als 
zentrales Kennzeichen der Kontrolle von IT-Arbeit (als Inbegriff neuer Arbeits- 
formen) gelten (Willke 1998; Heidenreich und Töpsch 1998; Töpsch, Menez 
und Malanowski 2001; Voß und Pongratz 1998), zeigt der Fall ServiceTec, dass 
auch hochqualifizierte IT-Arbeit sehr wohl direkt und bürokratisch kontrolliert 
werden kann. Haben schon einige frühere Studien darauf aufmerksam gemacht, 
dass die Annahmen in Bezug auf die Kontrolle von IT-Arbeit etwas einseitig 
sind und Formen direkter Kontrolle durchaus auch im Bereich hochqualifizierter 
„Wissensarbeit“ angewandt werden können (u.a. Barrett 2005; Mayer-Ahuja und 
Wolf 2005; auch schon Kraft und Dubnoff 1986), so überrascht doch das Maß, in 
dem es ServiceTec gelungen ist, den Arbeitsprozess der direkten Kontrolle durch 
das Management zu unterwerfen und die Beschäftigten in ihren Handlungs- und 
Verantwortungsspielräumen zu beschneiden. Die Rede von der „fabrikmäßigen“ 
Produktion von IT-Dienstleistungen, in der Managementliteratur seit einiger 
Zeit geradezu ein Ideal der zukünftigen Organisation von Arbeit im IT-Bereich, 
findet in Service Tec ein eindrucksvolles Beispiel. 


Bestätigt die vorliegende Studie damit also, dass die Internationalisierung der IT- 
Arbeit durchaus mit einer zunehmenden Industrialisierung der Arbeitsprozesse 
einhergehen kann, so widerlegt sie gleichzeitig die Prognose, dass dies der Fall 
sein muss, bzw. langfristig notwendig sein wird. Nun liegt der Neuigkeitswert 
der präsentierten Fallstudie bei NovoProd keineswegs primär darin, gezeigt zu 
haben, dass auch in international verteilt operierenden IT-Unternehmen die 
Arbeitsprozesse nach wie vor auf individuellen Kompetenzen und selbstorgani- 
sierten Abläufen beruhen können. Schon Kampf (2008, S. 373) kommt in seiner 
Studie zu dem Ergebnis, dass 


„[...] auf der einen Seite oftmals noch keine stabilen und systematisierten 
Formen der Arbeitsteilung gefunden [wurden] und ganzheitliche Rollen- 
profile [...] nach wie vor die Arbeit vieler IT-Beschäftigter [bestimmen]; 
auf der anderen Seite [...] auch die Standardisierung und Homogenisierung 
von Prozessen in den Unternehmen teilweise nicht weit fortgeschritten 


[ist].“ 
Die neue Erkenntnis, die aus der Fallstudie von NovoProd gezogen werden kann, 
ist, dass es sich dabei keinesfalls um „verschwindende“ Formen der Kontrolle 
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handeln muss. So behandelte Kämpf diese, noch auf die Selbstorganisationsfä- 
higkeiten der Beschäftigten abzielenden Formen der Arbeitsorganisation und 
-kontrolle eher als Überbleibsel früherer Phasen der IT-Industrie (vgl. Kapitel 1.2). 
Dieser Einschätzung muss vor dem Hintergrund der Ergebnisse dieser Studie 
widersprochen werden. Die präsentierte Fallstudie bei NovoProd zeigt deutlich, 
dass die Selbstorganisationsfähigkeiten und die kreativen Problemlösungsfähigkei- 
ten der Beschäftigten auch in international verteilt operierenden IT-Unternehmen 
nach wie vor eine wichtige Ressource für die Organisation der Arbeitsprozesse 
darstellen. Im von NovoProd etablierten globalen Entwicklungsnetzwerk wird 
ein sehr komplexes Produkt entwickelt und beinhaltet starke Interdependenzen 
zwischen den beteiligten Standorten und Entwicklungszentren. Der Charakter 
der globalen Zusammenarbeit und der dem indischen Standort zugewiesenen 
Tätigkeiten stellt für das Management bei NovoProd den zentralen Grund da- 
für dar, den Arbeitsprozess möglichst nicht weitreichend zu formalisieren und 
die intensive Kommunikation zwischen den Standorten zu kanalisieren. Die 
multilaterale und weitestgehend eigenverantwortliche Kommunikation und Ko- 
operation der Entwickler untereinander wird als notwendig erachtet, um mit den 
Unwägbarkeiten und häufigen (auch externen) Störungen des Arbeitsprozesses 
effektiv umzugehen. So konnte gezeigt werden, dass NovoProd vor allem damit 
zu kämpfen hat, dass die Arbeitsprozesse in einigen Teams gegenwärtig wesent- 
lich restriktiver kontrolliert werden müssen, als es beabsichtigt ist, weil die für 
den indischen Standort typischen Fluktuationsraten die Grundlagen der auf die 
Selbstorganisationsfähigkeiten der Beschäftigten gerichteten Kontrollstrategien 
unterlaufen. Die konstatierte permissive Kontrollstrategie NovoProds in seinem 
indischen Entwicklungszentrum kann daher keinesfalls als eine Art „Übergang- 
sphänomen“ gedeutet werden, das wahrscheinlich in naher Zukunft durch eine 
„nachholende Industrialisierung“ ersetzt wird. Zu gravierend sind bei NovoProd 
die Bedenken, dass ein „Bürokratiemonster“ die Flexibilität und Kreativität der 
Entwickler behindern und daher im Entwicklungsprozess ein Hindernis für alle 
Beteiligten werden könnte. 

Es darf zwar nicht verschwiegen werden, dass auch bei NovoProd die Inter- 
nationalisierung mit einer gewissen Form der Standardisierung der Arbeitsab- 
läufe einhergeht. Wie aus dem präsentierten Material hervorgeht, richtet sich 
diese Standardisierung als „Produktstandardisierung“ jedoch nur indirekt auf 
die Standardisierung der Arbeitsprozesse. Die Aufteilung des Gesamtprodukts 
in einzelne Module mit jeweils festgelegten Zuständigkeiten unterschiedlicher 
Standorte führt in der Folge durchaus zu einer stärkeren Arbeitsteilung, und 
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der Einflussbereich der Entwickler ist damit bei „verteilter Entwicklung“ ge- 
genüber einer Entwicklung, die vollständig an einem Standort in einem Team 
entwickelt wird, geringer. Allerdings bedeuten modulare Produktionsstruktu- 
ren nicht, dass auch die in diesen Modulen ablaufenden Arbeitsprozesse stark 
standardisiert werden (vgl. auch Flecker u.a. 2007, S.47ff.). Bei NovoProd sind 
zwar die Abhängigkeiten zwischen den einzelnen Modulen klar spezifiziert und 
standardisiert, die jeweils in den Modulen stattfindenden Arbeitsprozesse sollen 
jedoch permissiv kontrolliert werden. 


Die vorliegende Studie fügt der laufenden Debatte über die Veränderungen der 
Organisation und Kontrolle von Arbeit im Zuge der Internationalisierung der 
IT-Industrie eine wichtige Differenzierung hinzu. Ist es also falsch, weiterhin 
davon auszugehen, dass IT-Arbeit aufgrund ihres kreativen und wissensbasierten 
Charakters ausschließlich permissiv kontrolliert werden kann und lassen sich 
demnach auch wichtige Befunde für eine Zunahme restriktiver Kontrollformen 
in der IT-Industrie finden, so ist die Annahme, dass die Internationalisierung 
notwendigerweise mit restriktiven Kontrollstrategien einhergeht, als genauso ein- 
seitig zu verwerfen. Vielmehr verweisen die hier präsentierten Ergebnisse auf den 
konflikthaften und kontingenten Charakter der Reorganisationsbemühungen 
in international operierenden IT-Unternehmen. Auch im Zuge der Internatio- 
nalisierung der IT-Industrie bleibt die Form der Kontrolle des Arbeitsprozesses 
ein ,umkampftes Terrain“ (Edwards 1981). Eine Standardisierung und Forma- 
lisierung der Arbeitsprozesse kann dabei, anders als von den Vertretern der In- 
dustrialisierungsthese unterstellt, keinesfalls als Universallösung zur Bearbeitung 
des sich in neuer Form stellenden Transformationsproblems angesehen werden, 
sondern muss vielmehr als eine Möglichkeit gelten, mit den organisatorischen 
Herausforderungen global verteilter Arbeitsprozesse umzugehen, deren Erfolg 
und Angemessenheit jedoch an bestimmte Voraussetzungen und Bedingungen 
gebunden ist. 

Darin, nähere Erkenntnisse über die Einflussfaktoren zu Tage gefördert zu 
haben, die sich auf die Form der Reorganisationsbemühungen und die daraus 
folgenden Formen der Arbeitsprozesskontrolle in international operierenden 
IT-Unternehmen auswirken, darin liegt die zweite Leistung dieser Studie. 
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7.2 Betriebliche Reorganisationsmodi zwischen 
globalen Geschäftsmodellen und den 
Arbeitsmärkten der Standorte 


Anhand der beiden untersuchten Unternehmen konnte gezeigt werden, dass 
die zunehmende Internationalisierung der Arbeit in der II-Industrie mit ei- 
ner weitgehenden Industrialisierung der Arbeit einher gehen kann, aber nicht 
muss. So konnten anstatt einer eindeutigen Industrialisierungstendenz vielmehr 
unterschiedliche Reorganisationsmodi bei beiden untersuchten Unternehmen 
festgestellt werden, die sich auch in unterschiedlich restriktiven Formen der 
Arbeitskontrolle niederschlagen. 

Die Ergebnisse dieser Studie zeigen jedoch nicht nur die Unterschiedlichkeit 
der von den Unternehmen verfolgten Kontrollstrategien, sondern erlauben es 
darüber hinaus auch, Faktoren zu bestimmen, welche die jeweils verfolgten Kon- 
trollstrategien beeinflussen. Mit den Internationalisierungsvarianten (Captive- 
Offshoring/Offshore-Outsourcing) und der Situation auf dem indischen Ar- 
beitsmarkt wurden zwei zentrale Einflussfaktoren auf die jeweils verfolgten 
Reorganisationsstrategien herausgearbeitet. 


Als wesentliches Differenzierungsmerkmal der beiden Fälle wurde das jeweils 
verfolgte Geschäftsmodell des Unternehmens und die damit zusammenhängende 
Form der Internationalisierung von Arbeit berücksichtigt. Dieser Faktor erwies 
sich als entscheidend für die Frage, inwieweit das Unternehmen bestrebt ist, die 
Arbeitsprozesse zu standardisieren und zu formalisieren. 

So ließ sich am Beispiel von ServiceTec zeigen, dass die Art der von Service Tec 
erbrachten Leistungen und die für IT-Dienstleister typische Form der Kunden- 
bindung ganz wesentliche Auswirkungen auf die Organisation und Kontrolle 
der Arbeit haben und die „Industrialisierung“ der Arbeitsprozesse in diesem Fall 
stark begünstigen. 

Viele der von ServiceTec erbrachten Leistungen betreffen Tätigkeiten am un- 
teren Ende des „Software-Lifecycles“, wie die Programmierung und das Testen 
von Erweiterungen oder kundenspezifische Anpassungen von Standardsoftware- 
Produkten, bzw. die Pflege und Wartung von bereits im Betrieb befindlichen 
Systemen und Applikationen. Diese Tätigkeiten werden aus den Arbeitsprozes- 
sen der Kundenunternehmen herausgelöst und sind entsprechend häufig bereits 
von Kundenseite stark spezifiziert und formalisiert. Zudem sind solche Tätigkei- 
ten - wie im Falle von Wartungsprojekten - häufig wiederkehrender Natur. Es 


Reorganisationsmodi zwischen Geschäftsmodell und Standort 281 


konnte am Beispiel von Service Tec gezeigt werden, dass diese Tätigkeiten intern 
relativ leicht in kurztaktige Arbeitspakete für die Entwickler heruntergebrochen 
und prozessförmig organisiert werden können. So gab die vom Kunden kom- 
mende Fehlermeldung in den Wartungsprojekten bei Service Tec häufig bereits 
die Form der Arbeitspakte vor: jeder Beschäftigte erhält eine Fehlermeldung zur 
Bearbeitung. Die Zuweisung individuell zu bearbeitender Arbeitsaufgaben wird 
in diesem Fall also bereits durch die Form, in der die Arbeitsaufträge vom Kunden 
an den Dienstleister kommuniziert werden, beeinflusst. Doch auch in den Fällen, 
in denen es nicht um reine Wartungsaufgaben geht, beziehen sich die Tätigkeiten 
häufig auf weniger komplexe Erweiterungen bestehender Systeme. Damit wird 
das bestehende System bei den Kunden zu einer ersten Einschränkung für die 
Arbeit der Entwickler auf der Seite des Dienstleisters, denn es kann von diesen 
nicht, bzw. nur in Ausnahmefällen beeinflusst werden. Die Konventionen auf 
Seite der Kunden werden damit zu einem Rahmen, in dem sich die Entwickler in 
ihrer Arbeit halten müssen, und die dadurch schon eine gewisse Standardisierung 
für die Arbeitsprozesse des Dienstleisters bedingen. 

Stärker noch als die Art der an IT-Dienstleister ausgelagerten Tätigkeiten prägt 
der spezifische Kundenkontakt die Form der Arbeitsprozesse in jenen Unterneh- 
men. Der Einfluss des Kundenkontaktes erstreckt sich dabei auf unterschiedliche 
Ebenen. 

Zunächst zieht der Kundenkontakt eine typische Form der Arbeitsteilung 
nach sich. Für IT-Dienstleister besteht die Notwendigkeit auf der einen Seite 
in engem Kontakt zu ihren Kunden zu stehen, auf der anderen Seite aber auch 
Offshore-Entwicklungszentren in die Arbeitsprozesse einzubeziehen, um die 
Kostenvorteile des Offshore-Outsourcings zu realisieren. Aus diesen Anforderun- 
gen folgt die mittlerweile als typisch anzusehende Arbeitsteilung zwischen einer 
kundennahen Vertriebsniederlassung („Frontend“) und Entwicklungszentren in 
Niedriglohnregionen („Backend“). Wie sich zeigen ließ, ging diese interne Ar- 
beitsteilung bei ServiceTec mit einer asymmetrischen Verteilung von planenden 
bzw. konzeptionellen und ausführenden Tätigkeiten einher. Die Tätigkeiten, für 
die direkter und unmittelbarer Kontakt zum Kunden nötig ist, konzentrieren 
sich in den Onsite-Niederlassungen. Kernstück dieser kundennahen Tätigkei- 
ten waren bei ServiceTec die Verhandlungen über die Anforderungen an die 
Leistungen und die Planung der Leistungserbringung, wozu vor allem ein erstes 
technisches Design und ein mit dem Kunden abzustimmender Projektplan ge- 
hört. Sowohl das Design als auch der Projektplan beeinflussen maßgeblich den 
weiteren Verlauf des Projekts und stellen für die Entwickler in den Offshore- 
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Entwicklungszentren weitgehende Richtlinien für ihre Arbeit dar, auf die sie aus 
den Offshore-Entwicklungszentren jedoch nur geringfügig einwirken können. 

Zudem begnügen sich die meisten Kunden ServiceTecs nicht damit, die An- 
forderungen, das technische Design und evtl. die Projektpläne gemeinsam mit 
dem Dienstleister zu erstellen, sondern versuchen darüber hinaus auch, direkt in 
die Organisation der Projektarbeiten einzugreifen. Einerseits, indem anerkann- 
te Zertifizierungen für die Auftragsabwicklung (ISO9001, CMMI, Six Sigma 
o.ä.) verlangt werden, und andererseits, indem über vertragliche Vereinbarun- 
gen Bearbeitungszeiträume und regelmäßige Fortschrittsberichte eingefordert 
werden. 

Die Untersuchung Service Tecs hat demonstriert, wie weitreichend die Stan- 
dardisierungswirkungen der implementierten Prozessmodelle sind. Service Tec 
legt sehr großen Wert auf die umfassende Implementierung einer ganzen Reihe 
von international anerkannten Prozessmodellen. Gerade als indischer Anbieter 
von Offshore-Dienstleistungen hat ServiceTec noch mit großen Vorbehalten 
der Kunden zu kämpfen, die indischen IT-Dienstleistern keine hohe Qualität 
der Leistungserstellung zutrauen. So ist die Intensität, mit der bei ServiceTec 
die Prozessorientierung des eigenen Geschäftsmodells betont wird, nicht nur - 
wie später noch argumentiert wird - aber auch auf die spezielle Kundenbindung 
zurückzuführen. 

Eine ebenso entscheidende Rolle spielen die Kunden auch in Bezug auf die 
Überwachung der Arbeitsprozesse. So waren die Forderungen der Kunden nach 
Meldungen über Stand und Verlauf der Projektarbeiten in vielen Fällen bei 
ServiceTec wesentlich kurztaktiger als ServiceTec es von sich aus angestrebt hätte. 
In Wartungsprojekten richten sich die vorgegebenen Zeiten, in denen Fehler 
behoben sein müssen, häufig nach einer schematischen Klassifizierung eines 
Fehlers, der vertraglich ausgehandelte Bearbeitungszeiträume hinterlegt sind. Ein 
Verstoß gegen diese zeitlichen Vorgaben kann Grundlage für Strafzahlungen 
an den Kunden. Die zeitlichen Vorgaben für die Entwickler sind daher bei 
IT-Dienstleistern extrem starr und können auf der Teamebene in den Offshore- 
Entwicklungszentren von den Entwicklern nicht beeinflusst werden. 

Das von ServiceTec verfolgte Geschäftsmodell und die damit implizierte Form 
der Internationalisierung von Arbeit beinhalten also bereits wesentliche Treiber 
einer Standardisierung und Formalisierung der Arbeitsprozesse und grenzen 
die Handlungs- und Gestaltungsspielräume der Entwickler in den Offshore- 
Entwicklungszentren stark ein. 
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NovoProd hingegen, als Hersteller von Standardsoftware-Produkten, verfolgt 
einen ganz anderen Ansatz. Hier wird ein neues Software-Produkt in „verteilter 
Entwicklung“ hergestellt. Die Internationalisierung von Arbeit findet in diesem 
Fall innerhalb des Unternehmens statt (Captive Offshoring), beinhaltet also kei- 
ne „Auslagerung“ und eine damit zusammenhängende externe Kundenbindung. 
Das indische Entwicklungszentrum soll vielmehr einen wichtigen Teil zur Ent- 
wicklung eines neuen Softwareprodukts beitragen. Gegenüber ServiceTec konnte 
bei NovoProd gezeigt werden, dass das von NovoProd verfolgte Geschäfts- und 
Verlagerungsmodell Eigenschaften aufweist, die eher permissive Formen der 
Arbeitskontrolle im indischen Entwicklungszentrum begünstigen. 

Zunächst handelt es sich bei dem Arbeitsgegenstand um eine Produktinnova- 
tion NovoProds. Zwar wird auf bereits vorher genutzte Technologien zurück- 
gegriffen, die Form, in der diese Technologien eingesetzt werden, ist jedoch 
gänzlich neu im Produktportfolio NovoProds. Es gibt daher keine umfassenden 
formalen Vorgaben darüber, wie das neue Produkt zu entwickeln ist. Zudem 
entwickeln alle an der Entwicklung beteiligten Einheiten NovoProds ihren Teil 
parallel. Aus diesem Setup folgen erhebliche Unwägbarkeiten bei der Planung 
der Entwicklungsarbeiten. So können im indischen Entwicklungszentrum nicht 
alle nötigen Arbeitsschritte zur Entwicklung der Screens vom Management klar 
und verbindlich im Voraus spezifiziert werden, da die dort ablaufenden Arbeiten 
höchst anfällig für „externe Störungen“ durch die anderen beteiligten Teams 
sind. Diese Interdependenz der Arbeitsprozesse erschwert auch die zeitliche 
Strukturierung der Arbeiten. Zwar werden durch das Steuerungsgremium die 
Waves der Entwicklung festgelegt, doch dabei handelt es sich eher um Zeiträume 
von mehreren Monaten, innerhalb derer die zeitliche Planung relativ flexibel 
gehandhabt werden muss, um auf unvorhersehbare Ereignisse reagieren zu kön- 
nen. Die Untersuchung hat gezeigt, dass diese Gründe wesentlich dazu beitragen, 
dass NovoProd bei der Aufgabenorganisation darauf setzt, dass die Entwickler 
möglichst selbst ihre Aufgabenbearbeitung organisieren und auf die Unwägbar- 
keiten selbstständig und problemlösend reagieren. Grundlage dafür ist auch die 
intensive Kooperation innerhalb des Teams - die Beschäftigten erhalten zwar auch 
individuelle Arbeitspakete, jedoch sind diese häufig nur gemeinsam zu bearbeiten 
und auftretende Probleme erfordern ein gemeinsames Vorgehen. 

Die Interdependenz der „verteilten Entwicklung“ führt darüber hinaus auch 
zu hohen Abstimmungsbedarfen zwischen den beteiligten Einheiten. Zwar ist 
das Produkt in verschiedene Module zerlegt und die Trennung ist auch eindeu- 
tig gezogen, jedoch können Änderungen an bestimmten Teilen eines Moduls 
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Änderungen in anderen nach sich ziehen. Wenn demnach z.B. in der Plattform 
bestimmte Variablen verändert werden, muss auch der Entwickler bei Application 
diese Änderungen berücksichtigen. Es kann zwar konstatiert werden, dass Novo- 
Prod versucht, die Schnittstellen der Module möglichst zu standardisieren, jedoch 
treten im Laufe des Projektes auch an diesen Punkten Änderungen auf. Und auch 
wenn die Schnittstellen fix sind, besteht trotzdem erhöhter Informationsbedarf 
zwischen den Einheiten, um die Module optimal aufeinander abzustimmen. So 
ist die Kommunikationsintensität zwischen Vision, Platform und Application 
nach Aussagen der verantwortlichen Projektmanager so hoch, dass eine Kanali- 
sierung und Formalisierung der Kommunikation zwischen den Einheiten bei 
NovoProd wenn überhaupt möglich, dann eher hinderlich für die Effizienz der 
Arbeitsprozesse wäre. Auch hier verlässt sich NovoProd darauf, dass die inten- 
sive Kooperation und Kommunikation zwischen den beteiligten Einheiten am 
besten multilateral auf der Ebene der beteiligten Entwickler geregelt werden 
kann. Dementsprechend groß ist auch die Relevanz persönlicher Kontakte und 
Netzwerke zwischen den Beschäftigten bei NovoProd. 


Viele der in den Fallstudien herausgearbeiteten Unterschiede in der Form der 
Arbeitsprozesskontrolle können demnach auf die jeweils verfolgten Geschäfts- 
modelle der beiden Unternehmen zurückgeführt werden. Gleichzeitig zeigte 
sich jedoch auch, dass die Kontrollstrategien der beiden Unternehmen in ihren 
indischen Entwicklungszentren nicht ohne Berücksichtigung des lokalen Ar- 
beitsmarktes verstanden werden können. Besonders deutlich konnte dies bei 
NovoProd gezeigt werden. Die Probleme NovoProds, ihre strategische Zielstruk- 
tur im indischen Entwicklungszentrum zu implementieren, konnten auf die 
hohen Fluktuationsraten am indischen Standort zurückgeführt werden. Die da- 
durch verursachten häufigen Wechsel in der Zusammensetzung der Projektteams 
verhinderten entscheidend den Aufbau des bei NovoProd wichtigen Erfahrungs- 
wissens im Umgang mit den eingesetzten Technologien und Methodologien und 
den Besonderheiten des Produkts. Zudem dauert es sehr lange, die für die enge 
Kooperation nötigen persönlichen Netzwerke zu den anderen Einheiten Novo- 
Prods zu knüpfen, und die Kommunikations- und Kooperationsbeziehungen 
leiden dementsprechend, wenn Personen häufig das Unternehmen verlassen und 
ersetzt werden müssen. Da sich die Fluktuation bei NovoProd in den untersuch- 
ten Teams in der letzten Zeit sehr unterschiedlich entwickelt hatte, konnten die 
Konsequenzen hoher Fluktuationsraten auf die Form der Arbeitsorganisation 
und -kontrolle studiert werden. NovoProd ist in den stärker von Fluktuati- 
on betroffenen Teams gezwungen, wesentlich restriktivere Kontrollformen zu 
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implementieren, als es eigentlich der Firmenstrategie entspricht. Im Falle von 
NovoProd besteht also ein Konflikt zwischen der Kontrollstrategie und den im- 
plementierten, real vorfindlichen Formen der Arbeitsprozesskontrolle. Jedoch 
ist das Vorherrschen von restriktiven Kontrollformen in den genannten Teams 
kein Anzeichen einer grundsätzlich beabsichtigen „Industrialisierung“ der Ar- 
beitsprozesse als Geschäftsstrategie. Vielmehr lassen sie sich erst verstehen, wenn 
berücksichtigt wird, welche Voraussetzungen die Kontrollstrategie NovoProds 
hat, und inwiefern diese am indischen Standort erfüllt bzw. teilweise nicht erfüllt 
werden. 

Bei ServiceTec ließen sich die beiden Einflussfaktoren wesentlich weniger ein- 
deutig auseinanderhalten. Doch auch bei ServiceTec spielt der lokale Arbeits- 
markt eine wichtige Rolle für die Organisationform der Arbeitsprozesse. Als 
indisches Unternehmen hat ServiceTec jedoch eine etwas andere Beziehung zum 
indischen Arbeitsmarkt als NovoProd. So ist ServiceTec einerseits von jeher 
mit dem indischen Arbeitsmarkt konfrontiert gewesen und das Geschaftsmodell 
ServiceTecs hat sich unter dem Einfluss der indischen Arbeitsmarktverhaltnisse 
entwickelt. Andererseits hat ServiceTec als indisches IT-Dienstleistungsunter- 
nehmen den indischen IT-Arbeitsmarkt auch ganz wesentlich mitgestaltet. Die 
indische IT-Industrie ist gegenwärtig von IT-Dienstleistungsunternehmen do- 
miniert. Der enorme Personalbedarf der indischen IT-Dienstleister führt dazu, 
dass ein absoluter Großteil der Beschäftigten den Berufseinstieg in eben jenen 
Unternehmen erlebt und die ersten Erfahrungen mit der IT-Industrie bei diesen 
Beschäftigten daher auch durch genau jene Formen der Arbeitsorganisation und 
-kontrolle geprägt werden?. Ein Großteil der Jobs der indischen IT-Industrie 
befindet sich in den (meist indischen) IT-Dienstleistungsunternehmen. Es ist von 
daher kein Wunder, wenn sich die Beschäftigten auch in ihrer Karriereplanung 
wesentlich an den Anforderungsprofilen dieser Arbeitgeber orientieren (vgl. auch 
Upadhya und Vasavi 2006). Für ServiceTec ist daher die Situation auf dem indi- 
schen Arbeitsmarkt nicht in derselben Weise ein externer Einflussfaktor wie für 
NovoProd. 

Das ist auch der Grund, warum bei ServiceTec die Bemühungen, organisa- 
torisch mit dem Arbeitsmarkt umzugehen, geradezu „Hand in Hand“ gingen 
mit den Anforderungen an die Arbeitsprozesse, die auf das Geschäftsmodell 
zurückgeführt werden können. In der Folge verstärkt sich dadurch die empirisch 
konstatierte Tendenz der Standardisierung und Formalisierung der Arbeitsprozes- 


? Für eine ausführlichere Erörterung des Einflusses der indischen IT-Unternehmen auf die politi- 
sche und wirtschaftliche Struktur der indischen IT-Industrie, siehe auch Mayer-Ahuja 2011. 


286 Zusammenführung und Ausblick 


se bei NovoProd ganz erheblich. So kann diese Strategie nicht ausschließlich als 
Antwort auf externe Kundenbindung verstanden werden, sondern gleichzeitig als 
Ausdruck eines spezifischen Zugriffs auf den indischen Arbeitsmarkt. Wie sich an 
den zitierten Aussagen der Gesprächspartner bei ServiceTec ausführlich belegen 
ließ, spielt die Standardisierung der Arbeitsprozesse bei Service Tec immer in meh- 
rerlei Hinsicht eine Rolle: einmal als Qualitätsausweis dem Kunden gegenüber, 
darüber hinaus aber auch gleichzeitig immer als Möglichkeit, die Arbeitsprozesse 
gegen Personalfluktuation zu immunisieren und das beabsichtigte Wachstum des 
Unternehmens durch die Möglichkeit von Massenrekrutierungen und schneller 
Einarbeitungszeit zu gewährleisten. So muss auch für ServiceTec konstatiert 
werden, dass die real vorfindliche Form der Arbeitsorganisation und -kontrolle 
das Ergebnis eines Zusammenspiels von Geschäftsmodell und indischem Arbeits- 
markt ist, auch wenn das Zusammenwirken nicht ähnlich konflikthaft aufscheint 
wie bei NovoProd. 

Der interessante Punkt bei der Untersuchung des Arbeitsmarkteinflusses auf 
die Form der Arbeitsorganisation und -kontrolle der beiden untersuchten Fall- 
unternehmen ist, dass beide Unternehmen einen je spezifischen Umgang mit 
den Anforderungen des Arbeitsmarktes gefunden haben. Obwohl beide Unter- 
nehmen auf dem selben Arbeitsmarkt aktiv sind, erfahren sie aufgrund ihres 
spezifischen Geschäftsmodells eine jeweils spezifische Mischung aus Möglichkei- 
ten und Risiken. Die beiden untersuchten Unternehmen verhielten sich dabei 
geradezu komplementär zueinander. 

ServiceTec positioniert sich vor allem im Bereich der Berufseinsteiger, rekru- 
tiert eine große Zahl von Uniabsolventen, schult diese intensiv und setzt sie 
anschließend flexibel je nach Bedarf im Unternehmen ein. Die Standardisierung 
der Arbeitsprozesse ist in diesem Zusammenhang Voraussetzung und Folge ei- 
nes solchen Vorgehens: einerseits dürfen die Tätigkeitsprofile der Entwickler 
nicht derart beschaffen sein, dass sie viel Erfahrung und vertiefte Kenntnisse in 
bestimmten Technologien, Geschäftsbereichen o.ä. erfordern, damit die Neu- 
eingestellten möglichst schnell produktiv mitarbeiten können. Die „industriali- 
sierten“ Arbeitsprozesse sind in dieser Hinsicht also die Voraussetzung für die 
Rekrutierungsstrategie. Gleichzeitig führen derart beschaffene Tätigkeitsprofile 
anderseits auch dazu, dass die Jobzufriedenheit der Beschäftigten gering ist und 
sie deshalb schnell an Wechsel der Tätigkeiten innerhalb wie außerhalb des Un- 
ternehmens denken. Die dadurch ausgelöste Fluktuation, entweder als Rotation 
innerhalb des Unternehmens oder durch den Wechsel zu einer anderen Firma, 
bildet wiederum den Grund für weitere Standardisierungsbestrebungen im Un- 
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ternehmen. In dieser Hinsicht ist die Fluktuation auf dem Arbeitsmarkt der 
Grund für Standardisierungsbemühungen, um die Arbeitsprozesse von einzelnen 
Beschäftigten unabhängig zu machen. Das Geschäftsmodell, das seinerseits bereits 
die Standardisierung der Arbeitsprozesse begünstigt, ermöglicht also Service Tec 
auf der einen Seite, eine solche Rekrutierungsstrategie zu verfolgen und damit 
auch die ehrgeizigen Wachstumspläne der letzten Jahre zu realisieren. Auf der 
anderen Seite wirkt die dadurch geschaffene Fluktuation gleichzeitig auch als 
äußerer Faktor auf ServiceTec und zwingt zu organisatorischen Maßnahmen, 
damit umzugehen. 

NovoProd hingegen fokussiert auf den Bereich der bereits berufserfahrenen 
Beschäftigten auf dem indischen Arbeitsmarkt, die ihre ersten Jahre meist in 
den indischen IT-Dienstleistungsunternehmen verbracht haben. Der geringere 
Personalbedarf aufgrund des langsamen Aufbaus des indischen Standortes und 
des spezifischen Geschäftsmodells, das wesentlich weniger personalintensiv ist 
als das der IT-Dienstleister, befähigt NovoProd dazu, gezielt jene Beschäftigten 
auszuwählen, die aufgrund der Art und Qualität der Arbeit eine Beschäftigung 
bei NovoProd anstreben und damit die Bereitschaft mitbringen, sich auch über 
längere Zeit intensiv in bestimmte Tätigkeiten zu vertiefen und einzuarbeiten - 
eine Bereitschaft auf der die strategische Zielstruktur NovoProds beruht. Das 
Geschäftsmodell NovoPords bietet diesen Beschäftigten auch die Möglichkei- 
ten, sich intensiv in bestimmte fachliche Spezialbereiche einzuarbeiten und in 
größerem Maße Verantwortung für ihre Tätigkeiten zu übernehmen. 

Die Rekrutierungsstrategien ServiceTecs und NovoProds koexistieren also in 
ihrer Unterschiedlichkeit, indem sie andere Personengruppen auf dem Arbeits- 
markt adressieren. Die Strategie ServiceTecs fungiert dabei geradezu als Voraus- 
setzung des Vorgehens NovoProds, indem in den indischen IT-Dienstleistern die 
Beschäftigten ihre ersten Erfahrungen mit der IT-Branche machen und gleichzei- 
tig die technischen Qualifikationen erweitern, die NovoProd in seiner Strategie 
für eine Beschäftigung voraussetzt. 

Ähnlich komplementär sind auch die Strategien im Umgang mit Personal- 
fluktuation. Es ist dabei wenig überraschend, dass ServiceTec angesichts der 
Rekrutierungsstrategie und den damit korrespondierenden Tätigkeitsprofilen 
grundsätzlich mit höheren Fluktuationsraten konfrontiert ist als NovoProd. 
Allerdings befähigt die Form der Arbeitsorganisation ServiceTec auch, diese 
Fluktuation organisatorisch zu kanalisieren, weil die Arbeitsprozesse auch von 
höheren Fluktuationsraten nicht gefährdet werden, wenngleich dies nicht bedeu- 
tet, dass ServiceTec sich nicht auch bemühen würde, die Fluktuationsraten zu 
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senken. Für NovoProds Strategie hingegen stellen Fluktuationsraten ein gravie- 
rendes Problem bei der Herstellung ihrer organisatorischen Zielstruktur dar. Da 
die Zielstruktur der Möglichkeit Grenzen setzt, die Arbeitsprozesse durch Stan- 
dardisierung und Formalisierung gegen Fluktuation zu immunisieren, genießen 
hier Maßnahmen zur Reduzierung der Personalfluktuation höchste Priorität. 

In ihrem Bemühen, die Flukuationsraten im Unternehmen zu senken, beto- 
nen beide Unternehmen die jeweiligen Vorzüge, die sich aus ihrem verfolgten 
Geschäftsmodell ergeben: ServiceTec kann seinen Beschäftigten aufgrund des 
rasanten Wachstums und der spezifischen Natur der Projektorganisation im 
IT-Dienstleitungsgeschäft schnelle Aufstiegsmöglichkeiten und damit auch attrak- 
tive und „planbare“ Karrierewege bieten. Zudem stellt die im Geschäftsmodell 
angelegte Möglichkeit eines „Onsite-Postings“ zum Kunden eine Attraktivität 
für die Beschäftigten dar. Dieser Bereich ist für NovoProd eher problematisch. 
Das Geschäftsmodell NovoProds beruht darauf, dass Beschäftigte in Niedrig- 
lohnregionen auch dort bleiben, weil ein Posting in eine Hochlohnregion den 
Kostenvorteil des globalen Setups schmälern würde und ein Onsite-Team, wie 
bei ServiceTec, nicht nötig ist”. Gleichzeitig ist das indische Entwicklungszen- 
trum auch Teil des Gesamtunternehmens, und der Möglichkeit, die Beschäftigten 
dort gänzlich anders zu behandeln als in den anderen Standorten, sind Grenzen 
gesetzt, wenn z.B. über mögliche Beförderungen und Gehaltssteigerungen im 
deutschen Mutterhaus entschieden wird. Die Rede von der „internal parity“ bei 
NovoProd verweist genau auf diesen Umstand, der in der Folge dazu führte, dass 
NovoProd in den Bereichen Gehaltsentwicklung und Karriereverläufe droht, den 
Anschluss an die Standards des indischen Standortes zu verlieren. 

NovoProd legt zum Zweck der Fluktuationsreduzierung den Schwerpunkt eher 
auf die arbeitsinhaltlichen Anreize für die Beschäftigten, indem attraktive Arbeit 
in neuen und anspruchsvollen Technologien und große Verantwortungsspielräu- 
me für die Beschäftigten angeboten werden. In diesem Bereich sind ServiceTec 
hingegen enge Grenzen gesetzt, bedeutet Arbeit bei einem Dienstleister doch, 
dass häufig mit veralteten Technologien der Kunden gearbeitet werden muss und 
die von Kunden an Dienstleister ausgelagerten Tätigkeiten oft in ihrer Komplexi- 
tät und ihrem Anspruch begrenzt sind. 

So wie sich bereits im Hinblick auf die Rekrutierungsstrategien beider Unter- 
nehmen konstatieren ließ, fokussieren beide Unternehmen auf unterschiedliche 


? Eine Ausnahme bilden die „Brückenköpfe“ - eine Funktion, für die Beschäftigte im indischen 
Entwicklungszentrum mangels Erfahrung und persönlicher Netzwerke am deutschen Standort 
nur selten geeignet sind. 
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Zielgruppen auf dem indischen Arbeitsmarkt. Dementsprechend unterscheiden 
sich auch die Bemühungen, für diese Zielgruppe attraktiv zu sein und diese 
Zielgruppe auch im Unternehmen zu halten. Daher sind sowohl ServiceTec als 
auch NovoProd, auch wenn sie beide in Indien operieren und damit auf den glei- 
chen Arbeitsmarkt angewiesen sind, mit unterschiedlichen Herausforderungen 
konfrontiert, da sie den indischen Arbeitsmarkt in einer jeweils eigenen Weise 
adressieren und organisatorisch zu bearbeiten versuchen. 


Die Ergebnisse dieser Studie verweisen damit auf ein sehr komplexes Wechselspiel 
zwischen den von Unternehmen verfolgten Internationalisierungsstrategien (und 
den damit zusammenhängenden Geschäftsmodellen) und den Arbeitsmarkt- 
Bedingungen am jeweiligen Standort, das die Formen der Arbeitsorganisation 
und -kontrolle im Zuge der Internationalisierung der TI-Industrie wesentlich 
beeinflusst. 


7.3 Zur zukünftigen Untersuchung betrieblicher 
Reorganisationsmodi im Zuge der 
Internationalisierung der IT-Industrie 


Der Reichweite der vorliegenden Studie sind aufgrund des gewahlten Designs 
Grenzen gesetzt. So beschränkte sie sich mit einem deutschen Produkthersteller 
und einem indischen IT-Dienstleister zwar auf zwei typische, nichtsdestotrotz 
aber nur auf zwei Fälle. Ebenso wurde mit Indien zwar der gegenwärtig wichtigste 
Offshore-Standort, aber eben nur ein Standort in die Untersuchung einbezogen. 
Die Ergebnisse dieser Studie verweisen ganz zentral auf den kontingenten Cha- 
rakter der Entwicklung der Formen von Arbeitsorganisation und -kontrolle 
im Zuge ihrer Internationalisierung, indem sie mit den variierenden Internatio- 
nalisierungswegen und den Arbeitsmärkten der Ziel-Standorte zwei Faktoren 
herausgearbeitet hat, die in ihrem Wechselspiel die betrieblichen Reorganisati- 
onsmodi von Arbeit wesentlich beeinflussen. Damit rufen die Ergebnisse zur 
Vorsicht auf, aus den präsentierten Fällen stark verallgemeinernde Aussagen 
zu ziehen. Immerhin war die Studie angetreten, die in der Debatte prominen- 
te „Industrialisierungsthese“, die eine eher einheitliche Veränderungsdynamik 
der Gesamtbranche prognostiziert, zu kritisieren. Dementsprechend ist nicht 
beabsichtigt, aus den beiden ausführlich erläuterten (Re-)Organisationsmodi bei 
ServiceTec und NovoProd repräsentative Aussagen zu Formen der Arbeitsorgani- 
sation und -kontrolle in international operierenden IT-Unternehmen abzuleiten. 


290 Zusammenführung und Ausblick 


So wenig von der Form der Arbeitsorganisation und -kontrolle von ServiceTec 
generell auf die Reorganisation von Arbeit im Bereich der IT-Dienstleistungen 
geschlossen werden darf, so wenig gilt dies auch für NovoProd und den Bereich 
der Standardsoftware-Entwickler. 

Ebenso wurden mit den verfolgten Geschäftsmodellen und den Arbeitsmärk- 
ten vor Ort zwar zwei Faktoren herausgearbeitet, die in Bezug auf die betriebli- 
chen Reorganisationsmodi von besonderer Bedeutung sind, jedoch kann kaum 
behauptet werden, mit diesen beiden Faktoren die Varianz betrieblicher Kontroll- 
strategien im Zuge der Internationalisierung der IT-Industrie umfassend erklären 
zu können. 

Vielmehr sollten die präsentierten Ergebnisse dieser Studie als Plädoyer für 
weitere - und differenzierte - Forschung in diesem Bereich verstanden werden. 
Die Vertreter der „Industrialiserungsthese“ weisen zurecht darauf hin, dass die 
Formen der Organisation und Kontrolle von Arbeit im Zuge der Internationali- 
serung der IT-Industrie in Bewegung geraten und dass es Anzeichen dafür gibt, 
dass sich die traditionell eher permissiven Formen der Kontrolle von IT-Arbeit 
in einigen Bereichen in Richtung zunehmend restriktiver Kontrollformen verän- 
dern. Daher bildet die zunehmende Internationalisierung der IT-Industrie einen 
spannenden und wichtigen Forschungsgegenstand. Falsch wäre aber, aus diesen 
Anzeichen einen branchenweiten „Metatrend“ abzuleiten. Schon der begrenzte 
Zugriff der vorliegenden Studie zeigt, dass die Etablierung globaler Produktionss- 
trukturen ganz unterschiedliche Strategien im Hinblick auf die Organisation und 
Kontrolle von Arbeit beinhalten kann. 

Diese Studie zu zwei Einflussfaktoren auf die betrieblichen Reorganisations- 
modi von Arbeit im Zuge der Internationalisierung der IT-Industrie sollte daher 
als Auftakt zu einer Forschung verstanden werden, die sich der entstehenden 
„neuen Geographie“ der IT-Industrie empirisch differenziert annähert und die 
Folgen der Internationalisierung für die Beschäftigten untersucht. Zukünftige 
Forschung wird nicht nur weitere Standorte in die Untersuchung mit einbeziehen 
müssen, sondern zudem weitere Faktoren zu identifizieren haben, die sich auf die 
betrieblichen Reorganisationsmodi von Arbeit auswirken, um der Komplexität 
der Entwicklung gerecht zu werden. 


8 Anhang 


8.1 Interviews bei ServiceTec 


Tabelle 8.1: Interviews bei ServiceTec in Deutschland (SD) und Indien (SI) 


Nummer | Standort | Geschlecht Funktion 

1 SI w Entwicklerin 

2 SI w Entwicklerin 

3 SI m Projektmanager 

4 SI m höheres Management 
5 SI w höheres Management 
6 SI m Senior Projektmanager 
7 SI m Personalabteilung 

8 SI 3xm Vertreter des Gebäudemanagements 
9 SI m höheres Management 
10 SI w Personalabteilung (Cultural Trainings) 
11 SI m höheres Management 
12 SI w Modulleiterin 

13 SI w Entwicklerin 

14 SI m Modulleiter 

15 SI m höheres Management 
16 SI m höheres Management 
17 SI m Senior Projektmanager 
18 SI w Kundenbetreuerin 
19 SI m Projektmanager 
20 SI m Entwickler 
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Nummer | Standort | Geschlecht Funktion 

21 SI w Entwicklerin 
22 SI w Modulleiterin 

1 SD m Kundenbetreuer 

2 SD m Senior Software Architekt 

3 SD m Kundenbetreuer 

4 SD m Kundenbetreuer 

5 SD w Senior Kundenbetreuerin 

6 SD m Business Development Manager 
7 SD m höheres Management 

8 SD m Senior Projektmanager 

9 SD w Personalabteilung 


8.2 Interviews bei NovoProd 


Tabelle 8.2: Interviews bei NovoProd in Deutschland (ND) und Indien (NI) 


Nummer | Standort | Geschlecht Funktion 

1 NI m Personalmanager 
2 NI m Entwickler 

3 NI w Entwicklerin 

4 NI m Personalmanager 
5 NI m Qualitätsbeauftragter 
6 NI m Personalmanager 
7 NI m Projektmanager 
8 NI m Entwickler 

9 NI m Entwickler 
10 NI m Entwickler 
11 NI m Projektmanager 
12 NI m Entwickler 
13 NI m fachlicher Leiter 
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Nummer | Standort | Geschlecht Funktion 
14 NI m Entwickler 
15 NI m Personalabteilung 
16 NI m Personalabteilung 
17 NI w Projektmanagerin 
18 NI m Qualitätsbeauftragter 
19 NI w Qualitätsbeauftragte 
20 NI m Projektmanager 
21 NI m Entwickler 
22 NI m fachlicher Leiter 
23 NI m Entwickler 
24 NI m Personalmanager 
25 NI m Personalmanager 
26 NI m höheres Management 
27 NI m Projektmanager 
28 NI m fachlicher Leiter 
29 NI m Vertreter des Gebäudemanagements 
1 ND m höheres Management 
2 ND m Entwickler 
3 ND w Personalabteilung 
4 ND m Entwickler 
5 ND m Software-Architekt 
6 ND m höheres Management 
7 ND m Software-Architekt 
8 ND m fachlicher Leiter 
9 ND m Personalabteilung 
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N in den Bereichen Softwareentwicklung und IT-Dienstleistungen galt lan- 
ge Zeit als weitgehend resistent gegen die internationale Verlagerung. Doch 
spätestens seit Mitte der 1990er Jahre hat sich das Bild grundsätzlich gewandelt und 
auch in diesem Bereich der Wirtschaft begannen Unternehmen, ihre Produktion zu- 
nehmend zu internationalisieren. Der Internationalisierung wird in der Folge zugeschrie- 
ben, die Formen der Arbeitsorganisation und -kontrolle in dieser Branche grundsätzlich 
zu verändern, da die globale Verlagerung von Arbeitsprozessen deren zunehmende Stan- 
dardisierung und Formalisierung nach sich ziehe und damit die Arbeit der IT-Beschäf- 
tigten in wesentlich direkterer Form der Kontrolle durch das Management unterwerfe. 
Entgegen dieser Prognose zeigt die vorliegende Arbeit unter Rückgriff auf zwei 
Fallstudien in transnational operierenden IT-Unternehmen, dass sich in der IT-Industrie im 
Zuge der Internationalisierung weniger einheitliche Tendenzen der Arbeitsorganisation und 
-kontrolle durchsetzen. Vielmehr setzen sich unterschiedliche Reorganisationsmodi von 
Arbeit durch, die mit unterschiedlichen Folgen für die Arbeitssituation der Beschäftigten 
einhergehen und von dem dynamischen Wechselspiel zwischen variierenden Internatio- 
nalisierungswegen innerhalb der IT-Industrie und den institutionellen Gegebenheiten der 
Offshore-Standorte geprägt sind. 
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